refactor(error-handler): pipe error-responses through error-middleware

[JPSchellenberg]

This change makes the server conform with the express-style to handle errrors: https://expressjs.com/en/guide/error-handling.html It adds a central errorHandler middleware at the end of the middleware-chain, which is called when a handler calls the next(error) function with an argument. (Usually an error) This allows us to remove quite a lot sentry imports and it provides a central place to send back an error.

[sr258]

Without having had a closer look:

The new approach should allow customizing the Sentry report so that the error titles are more helpful and aggregate correctly. E.g. they shouldn't contain specific paths in the title that prevent aggregation. This is a serious drawback in the current way error reports work. You have to make sure the generic error handler doesn't prevent this.

[JPSchellenberg]

Yes, I have that in mind. The most important aspect of this change is to have a standardised error-response for the client with a traceable error-code.

[sr258]

Does it make sense to send the error to Sentry from the client or couldn't we already send it to from the server together with all stack traces etc.?