API Client Error Communication

[nbauernfeind]

The current approach to error handling is:

• if it is an expected error, there should be plumbed code firing a gRPC Status Exception
• all non gRPC status exceptions are "unexpected" errors

The result of this is:

• proper error communication is very spotty; there are plenty of expected errors that hit the UUID code path (formula compilation, for example)

This issue will be updated after we formalize a plan around error handling; to be updated after meeting on June 30th, 2021 (ping @nbauernfeind / @rcaudy if not updated within a few days).

[rcaudy]

In our meeting today, we concluded that the baseline behavior should change. We will offer 3 "modes":

1. The current approach as summarized by Nate.
2. A middle approach where we process exceptions in order to build a message sans stack trace details.
3. The DHE approach, wherein we send full stack traces.

In all 3 modes, we will continue to include a UUID linking the error to the associated log message.

[nbauernfeind]

Table Update Size Listeners are currently directly sending the LTM propagated error. This needs to be resolved as part of this issue, too. (There is a TODO marked in the code.)

[nbauernfeind]

Session Service's termination notification request also needs to abide by these rules.