refactor(qp): introduce Single/Multi state for FetchGraph and steps

[dotansimha]

The "state" representation of a fetch step and fetch graph.

We split the work we do on the FetchGraph to to distinct parts:

1. Graph building: mainly happens in fetch_step.rs and is using SingleTypeFetchStep as state.
   This ensures that the step is built with a single type in mind.
2. Graph optimization: mainly happens in fetch/optimize/ files, and using MultiTypeFetchStep as state.
   This ensures that the step is optimized with multiple types in mind.

With this setup, we can ensure that some parts of the logic/capabilities that can be performed on a selection set or a step are limited,
and either scoped to a single type or a multi-type context.

TODO

• introduce a new struct for dealing with fetch-step selections
• use typestate pattern to represent different state of the selections (before/after optimizations)
• refactor output
• refactor input
• try to actually produce multi-type fetch-steps
• add new test to make sure the bench operation works
• pass ci and audit tests
• play along with Fix union overfetching #279
• apply sibling merging fix from Fix: Avoid infinite loop when merging siblings #282
• try to avoid cloning with switching state (refactor(qp): introduce Single/Multi state for FetchGraph and steps #280 (review))
• prettier code, avoid expect and try_as_single

[gemini-code-assist]

Summary of Changes

Hello @dotansimha, I'm Gemini Code Assist¹! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!

This pull request significantly refactors the query planner's internal representation of fetch graphs and steps. By introducing a type-state pattern and a dedicated structure for managing selection sets, the changes aim to enhance the clarity, correctness, and extensibility of the query planning logic, especially for advanced scenarios involving federated queries and type-specific selections.

Highlights

• Type-State Refactoring: The FetchGraph and FetchStepData structs have been refactored to use a type-state pattern, generic over SingleTypeFetchStep or MultiTypeFetchStep. This allows for more precise modeling of fetch steps during different phases of query planning, distinguishing between single-type and multi-type selection handling.
• Centralized Selection Management: A new FetchStepSelections struct has been introduced to centralize the management of output selection sets for fetch steps. This replaces the previous TypeAwareSelection for output and provides robust mechanisms for handling selections across multiple types, merging, and applying aliases.
• Two-Phase Graph Construction: The fetch graph is now initially constructed with SingleTypeFetchStep for simpler, single-type selections. After this initial phase, it is explicitly converted to MultiTypeFetchStep before optimization, enabling more complex multi-type selection handling and optimizations.
• Improved Error Reporting: The UnsupportedFieldInEntities error variant has been enhanced to include both the type name and the field name, providing more detailed context for debugging minification errors.
• Dependency Downgrades: Several Cargo.lock dependencies, including clap, hyper-util, rustls, and winnow, have been downgraded to earlier versions.
• New Benchmark Test: A new test, test_bench_operation, has been added to benchmark the query planner's performance and correctness with a larger, more complex GraphQL operation and supergraph schema.

Using Gemini Code Assist

The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.

Invoking Gemini

You can request assistance from Gemini at any point in your pull request via creating an issue comment (i.e. comment on the pull request page) using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands.

Feature	Command	Description
Code Review	/gemini review	Performs a code review for the current pull request in its current state.
Pull Request Summary	/gemini summary	Provides a summary of the current pull request in its current state.
Comment	@gemini-code-assist	Responds in comments when explicitly tagged, both in issue comments and review comments.
Help	/gemini help	Displays a list of available commands.

Customization

To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.

Limitations & Feedback

Gemini Code Assist is currently in preview and may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments to provide feedback.

You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension.

Footnotes

1. Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution. ↩

[github-actions]

GraphQL over HTTP Audit Results

61 tests  ±0   61 ✅ ±0   0s ⏱️ ±0s
 1 suites ±0    0 💤 ±0 
 1 files   ±0    0 ❌ ±0 

Results for commit f2a22df. ± Comparison against base commit 7e1c0f6.

♻️ This comment has been updated with latest results.

[gemini-code-assist]

Code Review

This pull request introduces a significant and well-structured refactoring by introducing SingleTypeFetchStep and MultiTypeFetchStep states for FetchGraph and FetchStepData. This greatly improves type safety and clarity throughout the query planning process. The introduction of FetchStepSelections is also a great step towards better encapsulation of selection logic.

I've identified a few areas for improvement, mainly concerning potential panics in the new selections.rs module which should be addressed to ensure robustness. I've also noted some dependency downgrades in Cargo.lock that would be good to clarify.

Overall, this is a high-quality refactoring.

[github-actions]

✅ k6-benchmark results

     ✓ response code was 200
     ✓ no graphql errors
     ✓ valid response structure

     █ setup

     checks.........................: 100.00% ✓ 25986      ✗ 0   
     data_received..................: 763 MB  25 MB/s
     data_sent......................: 10 MB   337 kB/s
     http_req_blocked...............: avg=19.74µs  min=841ns   med=2.03µs   max=5.48ms   p(90)=2.77µs   p(95)=3.17µs  
     http_req_connecting............: avg=15.84µs  min=0s      med=0s       max=5.43ms   p(90)=0s       p(95)=0s      
     http_req_duration..............: avg=171ms    min=3.45ms  med=170.17ms max=342.81ms p(90)=205.55ms p(95)=221.85ms
       { expected_response:true }...: avg=171ms    min=3.45ms  med=170.17ms max=342.81ms p(90)=205.55ms p(95)=221.85ms
     http_req_failed................: 0.00%   ✓ 0          ✗ 8682
     http_req_receiving.............: avg=699.04µs min=33.26µs med=69.99µs  max=146.14ms p(90)=1.69ms   p(95)=2.73ms  
     http_req_sending...............: avg=51.28µs  min=6.43µs  med=12.88µs  max=9.75ms   p(90)=21.58µs  p(95)=32.2µs  
     http_req_tls_handshaking.......: avg=0s       min=0s      med=0s       max=0s       p(90)=0s       p(95)=0s      
     http_req_waiting...............: avg=170.25ms min=3.38ms  med=169.66ms max=319.42ms p(90)=204.3ms  p(95)=220.72ms
     http_reqs......................: 8682    287.606362/s
     iteration_duration.............: avg=173.49ms min=36.68ms med=170.62ms max=578.9ms  p(90)=206.4ms  p(95)=223.16ms
     iterations.....................: 8662    286.943827/s
     vus............................: 50      min=50       max=50
     vus_max........................: 50      min=50       max=50

[kamilkisiela]

We need to clone here?