Expand responsibility of middleware to also resolve databases

[gefjon]

Based on and targeting #5611 . I thought this was a significant enough change to be worth reviewing separately.

Description of Changes

The middleware responsible for the metric spacetime_http_response_size_bytes_total has to resolve a request's :name_or_identity from name to identity in order to compute the correct metrics label, and from identity to referent database in order to avoid allocating metrics labels for non-existent databases in response to ill-formed requests.

Prior to this commit, the middleware did said resolution, then discarded the results, and the specific route handlers did the same resolution again. With this commit, the middleware is expanded to be fully responsible for database resolution. It attaches the resolved Database record to the request as an extension, and the route handlers read that extension rather than reading and resolving the :name_or_identity themselves.

A small number of routes have behavior on non-existent databases other than returning 404. These 404s may occur either when a name is not bound to an identity, or when an identity is not bound to a database. (N.b. a name may be bound to an identity without that identity being bound to a database, which is a somewhat silly situation.) Rather than increasing the complexity of the middleware to cope with these behaviors or changing the behavior of these routes by applying the middleware to them, we opt to simply exclude these routes from the middleware, applying it only to routes which want the 404 response behavior.

The specific routes exluded from the middleware are:

• PUT /database/:name_or_identity, which creates a new database if the name is not already in use.
• DELETE /database/:name_or_identity, which is a no-op on a non-existent database.
• /database/:name_or_identity/identity, which only resolves a name to an identity, and does not check whether that identity refers to a database.
• GET /database/:name_or_identity/subscribe, already excluded prior to this commit, whose response egress is tracked by a different metric than the one used by this middleware.

All of the newly excluded routes are infrequent operations with small responses, and said responses are not user-controlled, so it's probably fine that they don't get counted by the egress metric.

API and ABI breaking changes

N/a

Expected complexity level and risk

Testing

• New automated tests that affected routes don't re-resolve names unnecessarily.
• Other behavior should be covered by existing tests.

[joshua-spacetime]

Excellent, thank you!