feat(server): Implement batch endpoint

[lcian]

Implements the actual logic for the batch endpoint.

The endpoint just streams over the request parts and executes them in sequence.
Nothing in the design prevents a future change where the server could reorder and/or batch the requests to the underlying backends, to achieve even greater efficiency.

I've tried my best to split this in different PRs, but this is still pretty big, sorry.
The main file that should be reviewed is objectstore-server/src/endpoints/batch.rs. The changes in other files are just renaming existing things.
(those changes should ideally go in other PRs but I currently don't have good workflows to manage stacked branches, so I just made them in this one)

This doesn't include tests, even though the components it relies on have their own unit tests, and I've also tested this manually using a script where I was manually crafting payloads.
After we implement batching in at least one client, we will add e2e that use it.

Close FS-239

[lcian]

@sentry review

[linear]

FS-239 Batching: Server-side API

[matt-codecov]

is there a failure-proof way to build an error part we could use here rather than just omit the operation from the response entirely?

[lcian]

I will rethink this, admittedly I don't like it very much as well.

[lcian]

@sentry review

[lcian]

@sentry review

[lcian]

@sentry review

[lcian]

I've made some changes, I think this looks much better now.

The most important thing is that Part::new cannot fail now as we use HeaderValue::from_static and take in a Option<HeaderValue> as opposed to a Option<&str>.

We also make the object key serialization infallible by base64 encoding the value -- in practice object keys cannot contain illegal values anyways, but these 2 concerns should, in principle, be separated -- this simplifies a lot of things.