[JSONSelection] Track location information for parsed structures using Ranged<T> trait and WithRange<T> wrapper

[benjamn]

In order to provide more helpful parsing and error messages for JSONSelection, and to enable IDE/LSP features like syntax highlighting and tooltip hovering in the future, the JSONSelection parser needs to track where each parsed substructure came from within the original source string.

The nom_locate crate was helpful for replacing raw &str inputs with the type Span<'a> = LocatedSpan<&'a str> type, which nom (mostly) seamlessly accepts everywhere &str was previously expected. However, while the LocatedSpan type makes it easy to determine the starting offset of a given AST structure, the ending offset typically needs to be derived from parsing the structure's children. To bootstrap this parsing from the bottom up, I found it helpful to add a parsed_span combinator to match specific concrete tokens and capture their range information.

This would all have been considerably easier if every AST structure was a struct, because then I could simply have added a range: Option<(usize, usize)> (aka range: OffsetRange) field to each struct, and then make sure that field gets populated during parsing. Where possible, that's what I did, but there are a number of AST structures that make more sense as enum types, and we also need to keep track of location information for primitive/string types that cannot store their own ranges.

To work with this variety of AST structures, I introduced a Ranged<T> trait, which is implemented by all the structures that can provide (or cheaply derive) their own ranges. For those that cannot, there's a WithRange<T> wrapper struct that implements Ranged<T>. I considered using WithRange<T> (note: fka Parsed<T>) for everything, but that proved cumbersome and redundant, so the later commits in this PR walk back the use of WithRange<T> to just the types that need it, leaving the rest to implement Ranged<T> directly, without a wrapper.

To make this range information immediately useful, I am now including it as one of the fields of the ApplyToError struct, making runtime apply_to_path errors easier to debug. I would also like to include range information (along with more descriptive error messages) in parse errors generated by nom, but I haven't found a good way to replace the opaque nom::error::Error objects (which only store the input string and an error code) with errors that allow custom messages and range information, so that will have to wait for a subsequent PR.

You can review this PR commit-by-commit if you like, but I changed my mind a few times (e.g. renaming Parsed<T> to WithRange<T> after adding Range<T>), so it might be easier to review the whole set of changes together.

[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

[lennyburdette]

i didn't go over this with a fine-toothed comb, but the overall structure looks sound and the tests look good. i'm inclined to merge this early, probably right after our next release, so we can iterate on diagnostics for the language server. thank you for this!

[nicholascioli]

Thanks for working through all of the comments! The only thing left is if you want to add a quick comment about the trailing space. Otherwise, feel free to squash and merge!