Refactoring Highs::run()

[jajhall]

Sufficient refactoring of Highs::run() has been done to enable #2635 to be fixed.

Split Highs::run() into a set of nested methods according to HighsRun.md, which includes chat about what still needs to be done. This will take time, so this PR avoids a long-lasting dev branch.

[jajhall]

Closes #2738

[Opt-Mucca]

I'm a big fan of refactoring this! Some current thoughts:

• I dislike calling optimizeHighs inside of runFromUserScaling. I'd rather a scale function and then an undoscale function on either side of the call.
• Why do we actually need runFromExe? Could this not just be run?
• I like the general breakdown (run-time options -> user scaling -> "mods")

[jajhall]

I'm a big fan of refactoring this! Some current thoughts:

• I dislike calling optimizeHighs inside of runFromUserScaling. I'd rather a scale function and then an undoscale function on either side of the call.

If I understand correctly, you're suggesting putting a scale function and then an undoscale function either side of optimizeHighs within runFromExe?

This does reduce the number of nested methods, and I can't think of circumstances where user scaling would need to be applied without the "Highs files" methods, so fair enough

• Why do we actually need runFromExe? Could this not just be run?

I find run to be so opaque, but if we eliminate runFromUserScaling then it's the only run method, so there's no distinction to be made.

• I like the general breakdown (run-time options -> user scaling -> "mods")

Thanks

[Opt-Mucca]

If I understand correctly, you're suggesting putting a scale function and then an undoscale function either side of optimizeHighs within runFromExe?

Yup!

[jajhall]

Thanks, I've simplified the calling structure.

Are you OK with this PR?

[Opt-Mucca]

Happy with the change!