Serial sectorstructure and fusionblocks dominate building transformers of product sectors #596

With #580, #581 and #592, most of the time spent building the braid transformers of product sectors goes into their serial preparation. That preparation is sectorstructure, degeneracystructure and fusionblocks, and it runs before the threaded part.

Building all transformers of one CTMRG iteration with fℤ₂ × U(1) × SU(2) × U(1) (D = 7) on 8 threads takes 19.5–20.6 s. 13.5–14.9 s of that is the serial preparation.

The cost comes from storing every tree pair. That's 5.6 M pairs from 1.3 M splitting and fusion trees, over 776 spaces:

• sectorstructure: about half the time hashes every pair into the Indices. The rest enumerates the trees.
• fusionblocks: about 40 % sorts the groups, with tuple comparisons of product sectors. About 15 % hashes the uncoupled sectors of every pair into the Dict.

Proposal

1. fusiontrees(W) keeps the splitting and fusion trees of every coupled sector, not the pairs.
   • A pair's position follows from the trees: offset[c] + (j₂ - 1) * n₁[c] + j₁.
   • A small AbstractIndices type would hand out positions as tokens, so gettoken/gettokenvalue and the call sites stay unchanged.
   • subblockstructure(W) would become a dictionary that shares those tokens.
2. fusionblocks groups each side and combines the groups.
   • The groups are keyed by the position of their uncoupled sectors among the sectors of each space, so the sort compares integers.
   • Every block is filled once, at its final size.

Prototype

The prototype gives identical transformers, block order included, on all transformers of the iteration (550 for SU(2), 554 for SU(3)). The spaces, construction, indexmanipulations, braidingtensor, diagonal and doubletree tests pass.

Baseline: main + #580 + #581 + #592 (as of 832ec10, plus the unique-product shortcut it has now). Both versions also preallocate the pair vector in sectorstructure. Measured on a shared machine at load 34–50, two rounds in the same run:

The serial part (SU(2) case) goes from 13.5–14.9 s to 5.3–7.5 s:

• fusionblocks: 6.6–8.0 s → 1.9–2.2 s;
• sectorstructure: 4.4–5.9 s → 2.2–2.8 s;
• degeneracystructure: unchanged.

Caching the trees of each side across spaces didn't pay off, so the prototype adds no new cache.

Questions

• fusiontrees(W) and subblockstructure(W) would no longer return an Indices and a Dictionary. Is that acceptable, or does other code rely on those types?
• The integer positions in fusionblocks depend on the order in which sectors(V) iterates, as the current sort key already does implicitly. Is that acceptable now that fusionblocks dominates?

Related: #581 (current fusionblocks), #587 (caching fusionblocks).