Add support for SumOfSquares cone

[blegat]

With this PR, when the user uses the sampling basis, e.g. with

@constraint(model, p in SOSCone(), zero_basis = BoxSampling(-ones(nvariables(p)), ones(nvariables(p))))

the constraint will be transformed to Hypatia.WSOSInterpNonnegativeCone and not all the way to PSD constraints!

A few things still need to happen before this can be part of a release. To use this, one needs the development version of StarAlgebras, MultivariateMoments and PolyJuMP as well as

• Lagrange basis JuliaAlgebra/MultivariateBases.jl#47
• Sampling basis SumOfSquares.jl#378
• Add set for low-rank constrained SDP MathOptInterface.jl#2198

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 96.68%. Comparing base (46a2b1c) to head (9836600).
Report is 2 commits behind head on master.

Additional details and impacted files

@@            Coverage Diff             @@
##           master     #844      +/-   ##
==========================================
- Coverage   96.80%   96.68%   -0.12%     
==========================================
  Files          55       56       +1     
  Lines        9086     9092       +6     
==========================================
- Hits         8796     8791       -5     
- Misses        290      301      +11     

☔ 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.

[blegat]

@chriscoey @lkapelevich This PR is now ready for your review :)
It allows not only for the specialized Hypatia cone to be used with SumOfSquares (once jump-dev/SumOfSquares.jl#383 is merged) but also with any other SDP using low-rank constraints with https://github.com/blegat/LowRankOpt.jl/

[blegat]

Not sure why codecov is complaining. Looking at its report, it is mentioning this line that is uncovered #851
Not sure why it's related to this PR but probably #851 would help

[lkapelevich]

@blegat could you explain what v.matrix and v.matrix.factor are?

My second question is... what happens if you make LRO a weak dependency instead of a requirement? Would it be a mess?

My third question is... your LRO sets are really general. So what if someone has a LinearCombinationInSet that can be naturally represented with Hypatia's LMI cone instead of WSOS?

[blegat]

Each vector v is the vectorization of the upper triangular part of the symmetric matrix. v.matrix is the symmetric matrix itself, here represented as a rank-1 PSD matrix and v.matrix.factor is the factor of that PSD matrix.
At the moment, I didn't hook into Hypatia's LMI cone, it can be left as a follow-up PR. If the user uses a Low-Rank that is not rank-1 nor PSD, LowRankOpt takes care of bridging it to rank-1 PSD for Hypatia.

what happens if you make LRO a weak dependency instead of a requirement? Would it be a mess?

No, that should be possible

[lkapelevich]

Aha, I didn't catch that LRO.One{T} is for rank-1. Cool! So the WSOS cone really is the best representation for those sets.

It could be nice not to add a hard dependency, but I don't feel strongly.

[blegat]

This is the part that would get complicated if it's an extension

[blegat]

As _PrimalRankOnePSD starts with an underscore, it can always be moved as an extension later in a non-breaking way