Avoid substituting keys that occur multiple times

[fjetter]

Closes #10645

I haven't run any widespread tests, yet. However, for the cases that are affected, this triggers the computation of a task twice and apparently also prohibits some kind of numpy optimization as reported in #10645

The graph topology here doesn't strike me as rare or very special

so the add in this graph is basically fused into a fused into a matmul-transpose blob / subgraphcallable that accepts two inputs that are identical. I would argue that it is a bug of blockwise_fusion that generates such a blob in the first place since by rewriting that subgraph callable it would be possible to accept just a single dependency, restoring this fusion again.

I'm not very familiar with the blockwise fusion code and was able to find this first.

With this PR the above graph optimizes to

This change effectively stops fusing because it detects this situation. If the blockwise fusion bug is fixed, it would fuse into one task (again) but without recomputing the intermediate result twice

cc @rjzamora

[fjetter]

I'm pretty sure this is a bug that would've been caught if this all was type annotated.

[fjetter]

I'm running our benchmarks to see if anything pops up. We don't have a X + 1; X.T @ X test but I mostly want to make sure no other workloads are negatively affected

[fjetter]

our benchmarks look good

[Illviljan]

Suggested change

	def test_donot_substitute_same_key_multiple_times():
	def test_donot_substitute_same_key_multiple_times() -> None:

If you add -> None to new tests mypy will be able to check them as well. I think it's good practice to just do it if you are worrying about the type hints.
It helps catch the edge cases that aren't always obvious when just type hinting the functions.