Make -> method registration more flexible and type-safe

[benjamn]

Previously, -> methods (#5762) were implemented as functions and registered in a lazy_static! map for dynamic lookup at runtime.

This PR refactors the system for registering methods, so there is now an ArrowMethod enum with a variant for each known method, and each method is now represented by a struct type that has an ::apply method, whose signature resembles the previous function implementations.

In the future, we can add other methods to these structs, so -> methods can programmatically define their interactions with the output shape of the JSONSelection, for example.

[svc-apollo-docs]

✅ Docs Preview Ready

No new or changed pages found.

[router-perf]

CI performance tests

• connectors-const - Connectors stress test that runs with a constant number of users
• const - Basic stress test that runs with a constant number of users
• demand-control-instrumented - A copy of the step test, but with demand control monitoring and metrics enabled
• demand-control-uninstrumented - A copy of the step test, but with demand control monitoring enabled
• enhanced-signature - Enhanced signature enabled
• events - Stress test for events with a lot of users and deduplication ENABLED
• events_big_cap_high_rate - Stress test for events with a lot of users, deduplication enabled and high rate event with a big queue capacity
• events_big_cap_high_rate_callback - Stress test for events with a lot of users, deduplication enabled and high rate event with a big queue capacity using callback mode
• events_callback - Stress test for events with a lot of users and deduplication ENABLED in callback mode
• events_without_dedup - Stress test for events with a lot of users and deduplication DISABLED
• events_without_dedup_callback - Stress test for events with a lot of users and deduplication DISABLED using callback mode
• extended-reference-mode - Extended reference mode enabled
• large-request - Stress test with a 1 MB request payload
• no-tracing - Basic stress test, no tracing
• reload - Reload test over a long period of time at a constant rate of users
• step-jemalloc-tuning - Clone of the basic stress test for jemalloc tuning
• step-local-metrics - Field stats that are generated from the router rather than FTV1
• step-with-prometheus - A copy of the step test with the Prometheus metrics exporter enabled
• step - Basic stress test that steps up the number of users over time
• xlarge-request - Stress test with 10 MB request payload
• xxlarge-request - Stress test with 100 MB request payload

[dylan-apollo]

Very excited for the enum!!! My only suggestion is that maybe strum would make to/from name conversions easier? But also maybe not...

[dylan-apollo]

Oh nice, don't think I've ever done a dyn Deref before, good to know that's possible.

[dylan-apollo]

We could make the design decision not to have multiple names, though. Seems like we should standardize on camelCase and not snake_case.

That would also mean we could use strum to impl both FromStr and Display for all the methods without all the boilerplate.

[dylan-apollo]

I guess strum would make it harder to do the public/future split. Might end up having to add a #[cfg(test)] to every future method...

[benjamn]

I'm open to ideas, though not previously familiar with strum.

I'd be ok with sticking to one method name/style, but I think it's worthwhile to keep passing method_name as an argument into the method apply/shape implementations, so there's only one spot in the code we need to change if we want to rename a method (compared to each method implicitly "knowing" its own name and encoding it into error messages, for example).

[dylan-apollo]

For sure. I thought about suggesting that the macro could inject the name, but I think we still want location data down in the implementation so it wouldn't save us much.