ServerError should hint at whether the issue is the input (400) or the server (500)

[czechboy0]

Motivation

At the moment, when the generated parsing code fails on the server, an error is thrown, which by default gets turned into the HTTP response status 500.

However, if e.g. a required query item was missing, that should return 400, conventionally.

Unfortunately, server adopters don't have a good way to even handle it in a middleware, as RuntimeError is internal.

Proposed solution

Details to be discussed, but we should offer some signal whether the underlying RuntimeError is "caused by input" (e.g. bad request) or "caused by server" (e.g. handler throws an error).

Probably should also offer an "audited error string" that we guarantee is safe to send back to the caller, for example "missing required query item 'foo'". As getting a 400 without details can be infuriating.

Some questions:

• is this a backwards compatible change?
• should this be done by conforming ServerError to the new protocol, and users opt in by adding the middleware? ([Proposal] SOAR-0011: Improved error handling #626)

Alternatives considered

No response

Additional information

No response

[czechboy0]

Actually, just closing this, as it's already covered by #609, so let's centralize the discussion there.