Fix and test adding of two QN conserving ITensorNetworks

[emstoudenmire]

This PR fixes an issue with summing two QN-conserving tensor networks when using the "directsum" backend.

The issue occurs when the input TNs have tensors with varying, non-zero flux, even though each TN has the same total flux. Before this PR, the code would directsum all the local tensors together, resulting in local tensors with "mixed flux" which is not allowed. As a side note, we may want to have directsum throw an error when this happens.

This PR orthogonalizes the input TNs to the same root vertex before proceeding with the directsum algorithm. With this orthogonalization step, the only way the directsum strategy could fail would be if the TNs had different total flux, which would be a user error.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 69.07%. Comparing base (245d23d) to head (6d039fa).
⚠️ Report is 1 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main     #296      +/-   ##
==========================================
+ Coverage   69.00%   69.07%   +0.06%     
==========================================
  Files          81       81              
  Lines        4027     4029       +2     
==========================================
+ Hits         2779     2783       +4     
+ Misses       1248     1246       -2     

Flag	Coverage Δ
docs	0.00% <0.00%> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

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

[mtfishman]

Looks like a reasonable solution, thanks for the fix.

For a broader context, ideally we would have tensor network addition (and other tensor network algebra like multiplication) implemented through the same sweep algorithm interface that we implement DMRG and TDVP (I think we can fit various algorithms like fitting, density matrix, etc. into that framework), but that's better to leave for ITensorNetworksNext.jl. That way it would automatically generalize to loopy networks using BP.

[mtfishman]

Ready to merge?

[emstoudenmire]

Yes, it’s a good goal for ITensorNetworksNext to absorb these algorithms into the sweeping algorithm layer. If thats simple to do it will be a good proof of the design.
I’ll go ahead and merge this one and we could even think about that change for this library but probably better to wait.