Use component_access_set to determine the set of conflicting accesses between two systems.

[andriyDev]

Objective

• Fixes Ambiguity reporting does not account for effects of Without query filters, leading to false positives #4381

Solution

• Replace component_access with component_access_set when determining conflicting systems during schedule building.
• All component_access() impls just forward to &component_access_set().combined_access, so we are essentially trading Access::is_compatible for FilteredAccessSet::is_compatible.
• FilteredAccessSet::get_conflicts internally calls combined_access.is_compatible as the first step, so we can remove that redundant check.

Testing

• Un-ignored a previously failing test now that it passes!
• Ran the build_schedule benchmark and got basically no change in the results. Perhaps are benchmarks are just not targetted towards this situation.

$ critcmp main fix-ambiguity -f 'build_schedule'
group                                          fix-ambiguity                          main
-----                                          -------------                          ----
build_schedule/1000_schedule                   1.00       2.9±0.02s        ? ?/sec    1.01       2.9±0.05s        ? ?/sec
build_schedule/1000_schedule_no_constraints    1.02     48.3±1.48ms        ? ?/sec    1.00     47.4±1.78ms        ? ?/sec
build_schedule/100_schedule                    1.00      9.9±0.17ms        ? ?/sec    1.06     10.5±0.32ms        ? ?/sec
build_schedule/100_schedule_no_constraints     1.00   804.7±21.85µs        ? ?/sec    1.03   828.7±19.36µs        ? ?/sec
build_schedule/500_schedule                    1.00    451.7±7.25ms        ? ?/sec    1.04   468.9±11.70ms        ? ?/sec
build_schedule/500_schedule_no_constraints     1.02     12.7±0.46ms        ? ?/sec    1.00     12.5±0.44ms        ? ?/sec

[chescock]

This seems good to me! I never understood why we used the coarser checking there.

The lack of change in benchmarks seems plausible. FilteredAccessSet::get_conflicts starts by calling combined_access().get_conflicts() and only checks the filters if there is a potential conflict. Any schedule that wasn't reporting conflicts under the old algorithm will pass that first check and not need to do any additional checking.

(And we perform the same FilteredAccessSet::get_conflicts checks in the multi-threaded executor, so I bet we could make a future change to somehow do the checks once and share the answers.)