refactor HTTP handling to use an openapi-compatible framework

I've seen a couple discussions on PRs since I joined the team where the possibility of refactoring our HTTP API route handling has come up. A couple of good reasons do to this (in my view) include:

• Make it easier to define enterprise-specific routes separately from OSS/Core routes.
• Make it possible to programmatically generate OpenAPI docs.

My suggestion, mostly due to being familiar with it, is to go with axum. With axum we can more easily separate enterprise from core routes (what we have today is somewhat complicated by the use of one large (HTTP_METHOD, HTTP_ROUTE) match block) and we can integrate an existing open api spec generator: https://docs.rs/aide/latest/aide/index.html

If we were to go with axum + aide, we get features like the ability to extended the axum-based spec generation with generated request type examples that help customers understand exactly how to construct different forms of our request types, eg https://github.com/tamasfe/aide/blob/master/examples/example-axum/src/todos/routes.rs#L110

Start by mapping the current HTTP API route handling and its large (HTTP_METHOD, HTTP_ROUTE) match block. Compare the proposed axum + aide approach with the linked aide example, then define how enterprise/Core route separation and generated OpenAPI docs would be validated. The issue names no files or tests, so repository exploration and design agreement are prerequisites.