System order ambiguities should be grouped into related sets

[alice-i-cecile]

What problem does this solve or what need does it fill?

When multiple systems are ambiguous with each other, each pair is currently reported independently.

This is challenging to read and reason about, as the correct fix often involves thinking about the group as a whole.

What solution would you like?

If a group of systems are all ambiguous with each other, report this as a single ambiguity.

What alternative(s) have you considered?

We could instead group agglomeratively: if A is ambiguous with both B and C (but B and C are fine), group them.

This is probably incorrect: those errors tend to be due to several independent problems.

Additional context

Please don't do this until #7267 is merged for the sake of my sanity.

[joseph-gio]

I attempted this before in #6071, though I ran into issues with non-deterministic grouping. This code might be helpful to anyone trying this in the future.

[maniwani]

To group by component, we'd have to take the ambiguities, insert them as edges into a collection of undirected graphs (one per contested component type), and then run a maximal clique detection algorithm on each graph.

Then, knowing all groups of "systems that conflict on component T at same time", we could either:

• just print them to the console
• try to merge them further first
  • sort and hash each Vec<NodeId> to build a HashMap<Vec<NodeId>, Vec<ComponentId>>

[maniwani]

Grouping by system is another option. We can skip "bar conflicts with foo" if we already logged "foo conflicts with bar".

foo
conflicts with:
    bar on [A, B, C]
    baz on [World]

bar
conflicts with:
    baz on [World]