feat(service): Refactor Error

[lcian]

This changes objectstore_service::Error from a thiserror enum to an Error struct with a mandatory ErrorKind and optional description and source.

This new Error struct has almost no From<T> implementations.
The intention here is to force the user to always specify a kind instead of blindly propagating everything with ?, which is one of the issues that our previous approach had.
objectstore_server::ApiErrorResponse can now convert service errors to the appropriate HTTP status code by looking at the kind, rather than mapping a variant (i.e. the type of the inner error in the previous approach) to a certain status code.

Implementation

For every kind, we have the associated functions Error::$kind which takes the message and the source, and the simpler Error::$kind_msg for when we don't have a source to attach.

An additional Error::from_reqwest util is provided that encapsulates some logic which we would have in multiple places where we want to transparently map GCS statuses to our statuses.
This applies in particular to multipart requests, where Objectstore acts more as a proxy and where statuses are more varied, but also to e.g. 502s, which we can now easily surface transparently as 502s instead of 500s, to let the client know it can retry the operation.

As a downside, this makes existing code that had a lot of ?s (e.g. the local_fs backend) more verbose, needing a .map_err(|e| Error::$kind(msg, e)) every time.

A middle-ground would be to implement From<T> for ServiceError for some types where we know where we 99% of the time want ErrorKind::Internal, e.g. serde_json::Error, io::Error, and the like.
Or even have a generic impl of From that defaults to Internal, but that's something I would like to avoid as it would make it way too easy to produce 500s, just like with the previous impl.

Close FS-358

[linear-code]

FS-358