fix(federation): fixed Selection::conditions to merge field's subselection's conditions when necessary

[duckki]

In Selection::conditions method, which is the Rust port of JS function conditionsOfSelection, has following comment:

                Selection::Field(_) => {
                    // The sub-selections of this field don't affect whether we should query this
                    // field, so we explicitly do not merge them in.
                    //
                    // PORT_NOTE: The JS codebase merges the sub-selections' conditions in with the
                    // field's conditions when field's selections are non-boolean. This is arguably
                    // a bug, so we've fixed it here.
                    Ok(self_conditions)
                }
                Selection::InlineFragment(inline) => {
                    Ok(self_conditions.merge(inline.selection_set.conditions()?))
                }

The comment suggested that the JS code was buggy and it was fixed in Rust port. But, it turned out that there are cases where the Selection::Field(...) case should merge with its subselection-set's conditions.

Example:

#!subgraph
type Query {
    test: T!
}

type T {
    id: ID!
    name: String!
    x: Int!
}

#!operation
query($v1: Boolean!) {
    test @include(if: $v1) {
        id @include(if: false)
    }
}

In the example above, the test selection's condition may become a Boolean(false), influenced by its sub-selection-set.

---

Checklist

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

• Changes are compatible[^1]
• Documentation[^2] completed
• Performance impact assessed and acceptable
• Tests added and passing[^3]
  • Unit Tests
  • Integration Tests
  • Manual Tests

[svc-apollo-docs]

✅ Docs Preview Ready

No new or changed pages found.

[github-actions]

@duckki, please consider creating a changeset entry in /.changesets/. These instructions describe the process and tooling.

[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

[duckki]

I made this PR to match JS QP. But, now I doubt this is the right way to handle the query.