Fix stackoverflow in renormalize_southwest_corner

[leburgel]

Bumped into this by accident: using renormalize_southwest_corner directly on an enlarged corner and its projectors gave a stackoverflow, must have been a typo.

[Yue-Zhengyuan]

Looking back on this, it seems that all four renormalize_xxxx_corner(quadrant, P_left, P_right) are simply wrappers to the same renormalize_corner(quadrant, P_left, P_right). How about we directly write, for example,

function renormalize_northwest_corner((row, col), enlarged_env, P_left, P_right)
    return renormalize_corner(
        enlarged_env[NORTHWEST, row, col],
        P_left[NORTH, row, col],
        P_right[WEST, _next(row, end), col],
    )
end

to reduce one layer of wrapping?

[leburgel]

I don't think this works, because the enlarged_env can also contain a sparse representation of the enlarged corners, as EnlargedCorner instances. So the extra layer is required to dispatch to the EnlargedCorner implementations like

function renormalize_southwest_corner(ec::EnlargedCorner, P_left, P_right)
    return renormalize_southwest_corner(ec.E_1, ec.C, ec.E_2, P_left, P_right, ec.A)
end

[codecov]

Codecov Report

❌ Patch coverage is 0% with 1 line in your changes missing coverage. Please review.

Files with missing lines	Patch %	Lines
...lgorithms/contractions/ctmrg/renormalize_corner.jl	0.00%	1 Missing ⚠️

Files with missing lines	Coverage Δ
...lgorithms/contractions/ctmrg/renormalize_corner.jl	43.85% <0.00%> (ø)

🚀 New features to boost your workflow:

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

[Yue-Zhengyuan]

Is it convenient to add some test coverage here? In #326, I observed that tests only cover half of the CTMRG code.

[leburgel]

Yes, we should add some coverage here before merging, seems like a good opportunity.