First pass at a feasibility checker.

[odow]

This is a significant item for JuMP 1.0, but there is debate on how
to define and implement distances for different sets.

See jump-dev/MathOptInterface.jl#1023 for the
last time this was attempted.

See https://github.com/matbesancon/MathOptSetDistances.jl for a WIP
package exploring the options.

This PR also only addresses primal feasibility. See
joaquimg/FeasibilityOptInterface.jl#1
for a WIP attempt at dual feasibility as well.

In future, the _distance_to_set definitions will be merged into MOI.

This PR is more about defining the JuMP-level interface so we can
change internal details without breaking compatibility of JuMP 1.0.

Edit: for example, if MOI introduces a AbstractDistance argument,
we can add a ; distance = DefaultDistance() kwarg to primal_feasibility_report
without violating compatibility.

For now I've implemented sets for MILP, since this should cover 90% of
users wishing to implement this. Perhaps for the trickier sets, we can tell
users to load MathOptSetDistances, and that package can contain heavier
dependencies for computing the minimum eigen-value, etc.

Closes #693

Doc preview: https://jump.dev/JuMP.jl/previews/PR2466/manual/solutions/#Checking-feasibility-of-solutions

[codecov]

Codecov Report

Merging #2466 (8f39dbf) into master (f6be919) will increase coverage by 0.07%.
The diff coverage is 100.00%.

@@            Coverage Diff             @@
##           master    #2466      +/-   ##
==========================================
+ Coverage   93.69%   93.76%   +0.07%     
==========================================
  Files          43       44       +1     
  Lines        5360     5424      +64     
==========================================
+ Hits         5022     5086      +64     
  Misses        338      338              

Impacted Files	Coverage Δ
src/JuMP.jl	82.90% <ø> (ø)
src/feasibility_checker.jl	100.00% <100.00%> (ø)

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update f6be919...8f39dbf. Read the comment docs.

[joaquimg]

Great work!

Does it work for non-linear?

+1 to move _distance_to_set to MOI. SOC is very simple. SDP can be done with julia base, even full eig decomposition is usually faster than any solver (some even do full eig decompositions in each iteration).

[odow]

No, it doesn't work for nonlinear yet. But I could add if there is interest. For the other cones, I vote that we leave them for now. They can be added to MOI later. This is more about getting the API for JuMP sorted. Adding extra distance_to_set definitions is non-breaking.

[matbesancon]

This is more about getting the API for JuMP sorted

The only risk I see is getting the API sorted for linear and then struggling to fit non-linear in there.

Also as said in the call this shouldn't be a blocker IMO, anything can be added in 1.+ while things cannot be changed in a breaking manner, which means we would be pushing features then blocked before 2.x. If it's fully there great, but I wouldn't push an interface just for having an interface defined.

I think this could be implemented (partially) at the MOI level?

[odow]

I meant that we should lock in

primal_feasibility_report(
     model::Model,
     [point::AbstractDict{VariableRef,Float64}];
     atol::Float64 = 0.0,
)::Dict{Any,Float64}

but not necessarily define a distance for every single set.

[odow]

Any other reviews?