nonbinary `fullmatch_try_recovery`option

[benthestatistician]

Currently fullmatch_try_recovery is either on or off. When on, "infeasibility recovery" is attempted whenever an infeasible problem is passed, even when the user has specified each of {min/mean/max}.controls.

The process was designed to address infeasibility after the user specified only min.controls and/or mean.controls. It should be possible to set the option so that it's invoked in this circumstance but not when each of {min/mean/max}.controls has been set. As can arise when a user is experimenting with combinations of settings to probe feasibility and/or match quality; in this case it's frustrating to have one's inputs overridden, particularly when the route to undoing that setting is rather obscure.

This new setting might become the default at next major or sub-major version release, with the current, more aggressive setting still available by appropriate setting of this option. Unless by then we've also changed what infeasibility recovery does, in such a way that it makes more sense to invoke in the current manner.

[benthestatistician]

Notes:

• Would be nice to have this for next major version (Next major version (0.10 or 1.0) changes #134)
• If somehow infeasibility recovery via max flow #200 gets dealt with first, this may become a little less pressing
• @josherrickson would you be willing to add this to your queue, i.e. self-assign? If you agree on course of action, of course.

[josherrickson]

Sorry, I'm just seeing this now.

Currently, recovery is entered based upon max.controls: fullmatch.R#L506 It doesn't look like min or mean is ever considered.

[benthestatistician]

I should review the problem behind my original posting -- reviewing this it wasn't entirely clear that I couldn't have fixed my problem by changing the value of the existing option.

(If so, then we may be able to improve user experience by making infeasibility recovery a full()/pairmatch() argument, as opposed to an option.)