remove 'presolve' hook

[mlubin]

@joehuchette, if this isn't really needed, I'd prefer to remove this functionality in favor of buildInternalModel(); ...; solve(). How badly does this break things?
Ref discussion in 28c8a5d.

[joehuchette]

As far as I know, it'll just break the example code I sent you today.

[joehuchette]

Should remove the export as well (or else it's going to stick around for like a year until someone rediscovers it...)

[mlubin]

Ah, didn't realize it was exported.

[coveralls]

Coverage decreased (-0.01%) when pulling 4d83255 on remove_presolve into c7418d3 on master.

[coveralls]

Coverage decreased (-0.01%) when pulling 4d83255 on remove_presolve into c7418d3 on master.

[joehuchette]

@juan-pablo-vielma pointed out that this was being used in CPLEX.jl to implement branch/incumbent callbacks. Any opposition to restoring?

[mlubin]

Could you use the buildInternalModel(); ...; solve() pattern instead?
You'll need to wrap solve with a new name, but that seems to be the standard approach currently for extensions.

[joehuchette]

It seems kludgy to me to force the user to use something like solve_with_extra_callbacks(m::JuMP.Model) since this isn't really an extension, more like an extra feature that lives in one of the solver packages.

In other words, something like

solve(m::StochasticModel)

is kosher, but since we can't add a new method to dispatch on m::Model, you lose the generic-ness in user code.

[mlubin]

Any code using incumbent or branching callbacks is already not generic. What about

solvecpx(m, branchcb = callback1, incumbentcb = callback2)

instead of

setBranchCallback(m, callback1)
setIncumbentCallback(m, callback2)
solve(m)

If we're planning on documenting the CPLEX callbacks and making it official that's one thing, but as it is now this would get things working without adding extra kludge to JuMP itself.
I do think we could use a way to plug into solve() for extensions, but a presolve hook isn't really sufficiently general.

[joehuchette]

I mean it ideally would look generic---the fact that CPLEX is the only solver to support it, and where exactly the code lives should be immaterial to the end user. What would a more general solve hook look like? I can reshape the code if you have something in mind, but as it is right now this serves a real purpose, seems reasonably general and useful, and is a pretty tiny addition to the codebase.

[mlubin]

Something like setSolveHook that gets called instead of the default solve if it's set, with a special keyword like solve(m, ignore_solve_hook=true) so that you could call JuMP's solve from inside of the solve hook.
Would this work for JuMPeR, @IainNZ?

[joehuchette]

Sounds reasonable to me.

[IainNZ]

Could we have a setHook with a solve or print option? That'd be the two awkward things with "RobustModel" resolved.