CompatHelper: bump compat for MPSKit to 0.12, (keep existing compat)

[github-actions]

This pull request changes the compat entry for the MPSKit package from 0.11 to 0.11, 0.12.
This keeps the compat entries for earlier versions.

Note: I have not tested your package with this new compat entry.
It is your responsibility to make sure that your package tests pass before you merge this pull request.

[codecov]

Codecov Report

Attention: Patch coverage is 65.58824% with 117 lines in your changes missing coverage. Please review.

Files with missing lines	Patch %	Lines
src/algorithms/contractions/vumps_contractions.jl	25.92%	80 Missing ⚠️
src/operators/transfermatrix.jl	73.13%	18 Missing ⚠️
src/environments/vumps_environments.jl	91.58%	9 Missing ⚠️
src/operators/derivatives.jl	50.00%	6 Missing ⚠️
src/algorithms/toolbox.jl	90.00%	2 Missing ⚠️
src/utility/svd.jl	84.61%	2 Missing ⚠️

Files with missing lines	Coverage Δ
src/PEPSKit.jl	87.50% <ø> (ø)
src/algorithms/contractions/ctmrg_contractions.jl	59.50% <100.00%> (ø)
src/algorithms/contractions/localoperator.jl	95.19% <ø> (ø)
src/algorithms/ctmrg/gaugefix.jl	98.00% <100.00%> (ø)
src/algorithms/ctmrg/simultaneous.jl	98.33% <100.00%> (ø)
src/algorithms/time_evolution/gatetools.jl	100.00% <ø> (ø)
src/algorithms/time_evolution/simpleupdate.jl	87.91% <ø> (ø)
src/networks/tensors.jl	66.66% <ø> (ø)
src/operators/models.jl	55.38% <100.00%> (ø)
src/states/infiniteweightpeps.jl	93.33% <ø> (ø)
... and 8 more

... and 2 files with indirect coverage changes

[pbrehmer]

This seems to work now, except for all the boundary MPS things. Note that we here update MPSKit, MPSKitModels, KrylovKit, VectorInterface, TensorKit and TensorOperations at once since that way it was easier to disentangle all the compat requirements.

Once we get the boundary MPS things going, I'll take a look at the Zygote compat PR and merge that ASAP.

[leburgel]

This should be almost good to go I think. Boundary MPS contractions are running, and I took the liberty to reorganize and merge things as best I could right now. There's still some things I would like to do (e.g. update the contractions to use @autoopt, etc...), but nothing that should be blocking this.

The MPSKit updates allow to remove a bit of redundant code here (e.g. additional derivative structs such as PEPS_∂∂AC and the likes), but there's still quite a lot of things that had to be overloaded to make things work here, even though the actual 'interface' bits are quite compact. If we either

• Remove the O<:MPOTensor restriction in the type parameter of the MPO types, so that we can define things like const InfiniteTransferPEPS{T<:PEPSTensor} = InfiniteMPO{Tuple{T,T}}
• Systematically remove some type restrictions on the operators occurring in the MPSKit methods, such that we can just pass our own structs as long as they adhere to a minimal interface

then we can just remove most of the boundary MPS code here and things will still just work. But this requires some work on MPSKit in the future, for now this is good enough I think.

[lkdvos]

Looks good to me! I left a few minor comments, and it looks indeed like it will be a lot nicer once we lift some of the type restrictions in MPSKit, but I like getting this merged already in the meantime.

[lkdvos]

Apologies for having a second round of comments, this really should be my final ones :).

I think I would still like to see the one remark about type piracy resolved, and restore the KrylovKit compat. Otherwise good to go!

Given the recent changes, and the restoration of compatibility. How do we feel about tagging this as a new (breaking) release?

[lkdvos]

If CI passes, good to go for me

[pbrehmer]

Given the recent changes, and the restoration of compatibility. How do we feel about tagging this as a new (breaking) release?

Sounds reasonable to me :-) But before that I would also like to bump the Zygote and OptimKit compat so that everything is up-to-date. I'll do that later today.

[lkdvos]

Fair warning that the OptimKit update is not possible yet, since that has to trickle through MPSKit first. If the Zygote update does not yield too much of a headache, I'm okay with getting that in before tagging a release, but fixing that should not be a breaking change.
I would really push on tagging a release sooner rather than later, so people can start working with released versions of the software again.