Implement `RelativeGap`

[odow]

Instead of passing off to the solver

LinQuadOptInterface.jl/src/solve.jl

Lines 244 to 246 in 812d334

	function MOI.get(model::LinQuadOptimizer, ::MOI.RelativeGap)
	return get_relative_mip_gap(model)
	end

we should implement this ourselves to avoid issues such as jump-dev/MathOptInterface.jl#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.