Fix the query hashing algorithm

[Geal]

This splits part of the work from #5255 to make it easier to merge. This PR only covers the fixes for the query hashing algorithm, which is currently used in entity caching, without integrating the changes to the query planner cache key.

---

Checklist

Complete the checklist (and note appropriate exceptions) before the PR is marked ready-for-review.

• Changes are compatible¹
• Documentation² completed
• Performance impact assessed and acceptable
• Tests added and passing³
  • Unit Tests
  • Integration Tests
  • Manual Tests

Exceptions

Note any exceptions here

Notes

Footnotes

1. It may be appropriate to bring upcoming changes to the attention of other (impacted) groups. Please endeavour to do this before seeking PR approval. The mechanism for doing this will vary considerably, so use your judgement as to how and when to do this. ↩

2. Configuration is an important part of many changes. Where applicable please try to document configuration examples. ↩

3. Tick whichever testing boxes are applicable. If you are adding Manual Tests, please document the manual testing (extensively) in the Exceptions. ↩

[IvanGoncharov]

As an idea for follow up PR: What if use struct destructuring (without ...) for accessing fields on schema?
In that way, we can ensure that all fields are considered for hashing, so if new fields are added to apollo-rs, they will result in compiler errors.
That way, we protect against stuff that would be added to the GraphQL spec in the future, e.g., support for directives in a new location.

[Geal]

it could be useful for the other structures we use elsewhere in the visitor. Here, the schema also holds a list of types, but the point of this algorithm would be to ignore irrelevant types

[IvanGoncharov]

I'm not 100% sure, but it looks like it also should hash @fromContext:
https://www.apollographql.com/docs/graphos/reference/federation/directives#fromcontext
I looked into apollo-federation, and it seems that Rust QP doesn't support it, but it is implemented in JS QP.
I don't think this directive will affect entity cache, because you also hash the selection set of subgraph query (I'm just assuming here)

However, this directive should affect QP (at least for the JS planner), so it's breaking QP caching.

[IvanGoncharov]

@Geal I triple checked this PR and it looks great 👍
The only thing I found is @fromContext, otherwise it is ready to be merged.

If @fromContext is not an issue, then just ping me on Slack and I will approve this one ASAP.

[Geal]

@IvanGoncharov I added the initial support for the context directives. I will take another look tomorrow, but I think the approach is sound:

• as we go through the query, whenever we encounter a @context directive, we record the type in a map context name -> [Type}
• when we encounter a field with the join__field directive and its contextArguments argument, then for each argument, we take the context name and selection
• we look up the types linked to that context name. Considering the way we go through the query and relevant types, it might return types that would not appear in this query, so it might be a bit stricter than necessary
• for each of those type, we then use the selection and hash that in the same way we handle @key and @requires

There are some assumptions in there that we might want to check, like what happens when a contextArgument refers to a context that we did not find in the query (maybe that would have been prevented at composition?)

[IvanGoncharov]

Converting to draft as result of internal discussion regarding the risks introduced by parent PR, see details in #5255