Merge stable/1.2 features to master

[yuxies]

• Update Interdiction type problem data reading in MibSModel;
• Update two Benders cuts to reflect the changes in MibS valid inequality paper;
• Add a fractional cut option to multiple cuts and update related control parameter settings; update print messages for several cuts;
• Fix bugs and clean up redundant statements or variables;
• All changes above are applied to (only) deterministic blocks in the master branch.

[CLAassistant]

All committers have signed the CLA.

[tkralphs]

So all the commits attributed to me were cherry-picked? What about the additional ones by you? I guess those were also cherry-picked?

[yuxies]

The commits before the force-push + yesterday's last two commits were cherry-picked from stable/1.2.

And other commits not related to stable/1.2 but I pushed to the same branch so they are still showing up here are

• a1bbeee: cleaned the rounding procedure of LR relaxation solution when creating bilevel; it also fixed a bug;
• 76cb6be and e166fac are preparation for the heurstic solution tag reorg, as the current open PR in stable/1.2... I am still working on it.

[tkralphs]

OK, so should I merge this then?

[yuxies]

will run some tests tonight and report the results here. After that should be yes.

[yuxies]

Ran experiments using version f735ff2 on both dataIBLP-DEN (w or w/o linking pool + different cut options) and MIBLP-XU(default, i.e. fractional + hypercube IC). The objective values obtained agree with previous builds. So the commits above should be ready to merge.

(Again, all the changes above are not tested with stochastic cases, and will need to do so sometime in the future.)

[tkralphs]

I'm looking at this again now and I don't really understand how you approached this. We merged the changes from stable to master around 29 Nov 2019 in f19a5a5. I think we should be able to do the same now to just make sure that no commits get lost. Once we have the merge done, then we can separately add your commits on top, as needed. But I also wonder whether any of your commits are also appropriate in stable. Should we commit them to stable first and then merge?

[yuxies]

Some of my (most recent) commits listed here have already been merged to stable/1.2, and some of them may not be applied now because they may be conflict with other commits merged in the past year.

The feasibility check module looks very different in the master version due to the introduction of stochastic scenarios. I will need to read through and think again before clean up.

[tkralphs]

OK, but it's still the case that all the changes from stable/1.2 were merged not that long ago. There haven't been a lot of commits since then. I don't see that we need to cherry pick, just a plain merge should be OK. There might be a few conflicts to resolve, but I don't see it as being something very difficult, unless I'm wrong.