[Perf] reuse renormalize_west_edge for all directions

[ogauthe]

This PR rewrites renormalize_north_edge, renormalize_east_edge and renormalize_south_edge to have them reuse renormalize_west_edge. renormalize_west_edge was rewritten in #229 to optimize the permutations. This PR fixes #220, part of #205.

• the formatter made changes in the tensor diagrams. I can undo them if you prefer minimizing the diff
• I added a test for a 4x4 unit cell with each bond different

[lkdvos]

Thanks for this!

I don't mind too much about the changes in the diagrams so feel free to leave them in if you like.

Is there any chance you could run a small benchmark comparing the performance of the different directions now, so we can easily conclude that the different directions have more or less the same performance?

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.

Files with missing lines	Coverage Δ
src/algorithms/contractions/ctmrg_contractions.jl	55.24% <100.00%> (-0.39%)	⬇️

... and 2 files with indirect coverage changes

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[ogauthe]

Is there any chance you could run a small benchmark comparing the performance of the different directions now, so we can easily conclude that the different directions have more or less the same performance?

for SU(2) D=11, median time using https://github.com/ogauthe/BenchmarkPEPS/blob/main/run/benchmark_ctmrg.jl
renormalize_north_edge: 190.0 ms
renormalize_east_edge: 192.2ms
renormalize_south_edge: 191.6 ms
renormalize_west_edge: 189.4 ms
it was 295 ms before this PR

SU(2) D=16:
renormalize_north_edge: 2.87 s
renormalize_east_edge: 2.91 s
renormalize_south_edge: 2.91 s
renormalize_west_edge: 3.08 s
it was 5.2 s before this PR

So for SU(2) at D=11 and D=16, the cost of the additional sandwich permute is smaller than the fluctuations in benchmark time.

EDIT: same story for U(1) at D=11
the 4 direction take 37 ± 1 ms

[lkdvos]

with the expected compile-time benefits, that's definitely sufficient for me.

I'll try and investigate why the docs build is failing, I'm not sure if this can be related to this PR

[lkdvos]

It seems like the documentation build is really just a result of a Documenter.jl update. I'm rerunning the MPSKitModels docs to see if that fixes it, but in the meantime, this should not hold back this PR.

[ogauthe]

I removed the partition function methods. The 2D Ising partition function example works, so I guess legs ordering is fine.

[lkdvos]

To me this looks like a good change: it improves overall performance while reducing the amount of code.
@leburgel or @pbrehmer , if there are no further opinions on this I will go ahead and merge this end of tomorrow, if the tests pass.

[leburgel]

Looks good to me!