Migrate from cvxopt to cvxpy (+osqp / clarabel)

[phschiele]

Checklist:

• Add unit tests for current formulation
• Migrate to CVXPY formulation

[phschiele]

@fabian-sp Replaced cvxopt with cvxpy.
Right now, I basically skip initialization and update. Once we can verify correctness, I'll use cvxpy parameters to speed up repeated canonicalizations, which will again use the initialization/update/solve methods.

Equality constrained tests are still failing.

Update:
I think there might be a sign error in main?

ncOPT/src/ncopt/sqpgs/main.py

Line 600 in f79b0db

] = -1

[fabian-sp]

For the record: the -1 was indeed incorrect, should have been a +1.

[fabian-sp]

@phschiele Did you run scripts/time_rosenbrock.py to see how the solve time for the toy example changed?
I somehow can't run this anymore, getting the error

NameError: name 'problem' is not defined

[fabian-sp]

Comparing main to this branch on the rosenbrock timing, I get:

main: 163 ms ± 4.08 ms
cvxpy-subroblem: 850 ms ± 5.35 ms

So somehow there seems to be some overhead/slower solving time due to cvxpy.

[fabian-sp]

Left some questions/comments, but can be merged

[fabian-sp]

Why not cvxpy?

[phschiele]

CVXPY comes with multiple solvers by default. cvxpy-base is only the modeling language itself, and we only install one solver (clarabel) explicitly. This makes maintenance a lot easier.

[fabian-sp]

My VS Code complains about the list, probably prefers the List form typing?

[fabian-sp]

What is the ruleset on whether to define a property or to initialize in the __init__? To me this looks slightly overcomplicated...

[phschiele]

I did it this way to prevent users from having to check if the problem has been initialized yet every time, since in the __init__ you would set it to None, right?

[fabian-sp]

Are the tested subproblems somehow special (that is, coming from a special case of the underlying problem)?

[phschiele]

They are the first iterates of the rosenbrock example, so not special.