Migrate from Trillium [part 9B]: Rewrite test infrastructure + remove all trillium deps

[jcjones]

Replace the entire trillium-based test harness with axum-native equivalents and remove every trillium dependency from the workspace. Are you ready for a PARTY? This one removes Trillium. Say goodnight.

test-support/* rewrite:

• TestRequest/TestResponse types using tower::ServiceExt::oneshot()
• ClientLogs rewritten as axum middleware capturing request/response bodies
• ApiMocks rewritten with host-based axum::Router dispatch
• User injection by smooshing them into parts.extensions which acts like the PermissionsActor was cached

src/ crate cleanup:

• Delete handler::origin_router, handler::proxy, ErrorHandler, and the DivviupApi trillium Handler struct
• Delete inject_integration_testing_user and inject_test_header_user middleware
• Rewrote src/api_mocks/*

tests/integration/*:

• All response_json() calls are now synchronous

Here we see the final destruction of the trillium alliance, and the end of its insignificant rebellion against our dependency tree.

I've left some more cleanup for Part 10, including refactoring 'with_state' to 'with_user' in ~100 callsites, and the restoration of remaining HTTP metrics.

[divergentdave]

User injection via X-Integration-Testing-User header (was in the trillium conn state)

I think we may need to go the other direction instead. Currently when doing a workspace-wide build, the test-header-injection feature on divviup-api is enabled, since test-support uses it. It would be easy to accidentally build and deploy this. If we instead use existing state methods to inject a user for in-process unit tests and integration tests, then we can rely on existing Axum APIs, before calling oneshot() to set up fixtures. We should only use the #[cfg]-gated user injection approach, header or no, for the out-of-process Docker integration tests.

[jcjones]

User injection via X-Integration-Testing-User header (was in the trillium conn state)

I think we may need to go the other direction instead. Currently when doing a workspace-wide build, the test-header-injection feature on divviup-api is enabled, since test-support uses it. It would be easy to accidentally build and deploy this. If we instead use existing state methods to inject a user for in-process unit tests and integration tests, then we can rely on existing Axum APIs, before calling oneshot() to set up fixtures. We should only use the #[cfg]-gated user injection approach, header or no, for the out-of-process Docker integration tests.

I intended to finangle this in Part 10, but there's no reason not to do it now and be rid of inject_test_header_user here, good call. The final form of what I wanted is now in 59da00f.

[tgeoghegan]

Might have more to say, but here's some comments to start.

[divergentdave]

nit: we should keep a blank line between the imports and this function