[JSONSelection] Support conditional ... fragment selections

[benjamn]

In order to handle REST endpoints that return a union of possible result types, it's often necessary to consider various discriminator fields in the response, select different fields depending on those discriminator fields, and (when working with GraphQL) specify concrete __typename strings to resolve abstract types. This PR introduces a new JSONSelection syntax to address these use cases.

To keep the new syntax unambiguous, a conditional fragment is always introduced by a ... token, followed by if (expression) { included fields }. Unconditional fragment spreads are not currently supported with this syntax. Optionally, additional else if and else clauses may follow.

In this example, we're using the runtime value of the kind field to determine which conditional fragment to apply:

id
title
... if (kind->eq("book")) {
  isbn
  author { name }
} else if (kind->eq("movie")) {
  director { name }
} else {
  kind
}
year

When working with GraphQL, this type discrimination syntax provides an easy place to specify concrete __typename strings based on the kind values:

id
title
... if (kind->eq("book")) {
  __typename: $("Book")
  isbn
  author { name }
} else if (kind->eq("movie")) {
  __typename: $("Movie")
  director { name }
} else {
  __typename: $("Unknown")
  kind
}
year

In the future, we may want to extend this syntax to allow named fragments (to reduce repetition across selection strings), as in GraphQL, but that seemed too ambitious for this initial PR.

[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

[benjamn]

Calling out this TODO as a topic we've previously discussed, but that becomes more urgent with conditional fragments: how should we merge fields (potentially coming from different fragments, with different subselections) when they collide?