Implement `RelativeGap`

[odow]

Instead of passing off to the solver https://github.com/JuliaOpt/LinQuadOptInterface.jl/blob/812d334cc26394f4409c782ebdf6b4cd16e9debe/src/solve.jl#L244-L246 we should implement this ourselves to avoid issues such as https://github.com/JuliaOpt/MathOptInterface.jl/issues/590.

[mtanneau]

This looks a bit out of scope to me.

I would rather make it clear in the docs that the (mathematical) definition of RelativeGap is up to the solver, and that different solvers may use different conventions.

[blegat]

We might have RawRelativeGap (solver specific) and RelativeGap (has a default implemenation in MOI)

[mtanneau]

We might have RawRelativeGap (solver specific) and RelativeGap (has a default implemenation in MOI)

IMHO, it is quite risky to start defining conventions at the LQOI/MOI level.

• This would open the door to having to define every single convention, e.g. feasibility (some solvers use absolute, some use relative; some will work on the scaled model, others on the unscaled, etc...).
• It would mean MOI/LQOI is responsible for handling all (potentially problematic) cases: primal bound is zero, primal & dual bounds have opposite signs, one of the bounds has infinite magnitude, etc... That some maintenance + issues to answer.
• It means enforcing a consistent behaviour over solvers, which are not consistent. In the case someone wants to influence that behaviour (say, by setting a gap tolerance), they might run into problems. For instance, if I set some RelativeGap tolerance and compare several solvers, I should ensure that 1) that value is properly passed to the solver and 2) that the solver satisfies it when it returns a solution. That cannot work, because solvers have different internal definitions.
• In the specific case of RelativeGap, solvers do have slightly different definitions (see here), however (expect for SCIP), the actual difference should be neglictible for most practical applications.