The mechanics we use to configure whether an unhandled
StorageRecoverableError should produce a crash report is not very
flexible. Because StorageRecoverableError is basically a type alias,
inheriting from it is essentially the same as inheriting from the type
it was pointing to when the inheritance was declared.

Therefore, if we want different categories of StorageRecoverableError
we need to rebuild them after changing what type
StorageRecoverableError points to.

Instead, RecoverableError now has a class attribute
"produce_crash_report" which controls whether a crash report will be
created when such exception is unhandled in a request handler.

To configure whether we want to produce crash reports, we just need to
update the class attribute. Once can also inherit from RecoverableError
and set a class attribute to a different value in the subtype. This is
what we do to make storage recoverable errors not produce crash reports.

Note than RecoverableError instances can "override" the
"produce_crash_report" setting by creating an instance attribute of the
same name.

Signed-off-by: Olivier Gayot <[email protected]>

Signed-off-by: Olivier Gayot <[email protected]>

In addition to returning a HTTP response of 422 (when configured to do
so), recoverable errors will now include two information in the HTTP
headers:

  * x-error-code: a unique identifier of the error category, e.g.,
    "storage-invalid-usage"
  * x-error-title: a description of the error category, subject to
    translation and encoded as a non-indented JSON string

This is basically one step towards implementing RFC 9457 (Problem
Details for HTTP APIs) ; which we may or may not decide to implement in
the future.

Signed-off-by: Olivier Gayot <[email protected]>