Add ability to strongly enforce settings validation

[bsculac]

Currently, settings validation queries follow a pattern of:

1. Conditional
2. If True, print info string
3. Print question string
4. Perform action if answer to question is yes

It is possible to have features that are incompatible and should not be run at the same time. The formulation above does not permit a run to refuse execution if the answer to the question is "no" (presumably answering "yes" would disable one of the offending options or otherwise make the run acceptable). What do we think about adding the ability to quit a run during settings validation without doing something like lambda: raise Error in the conditional?

@albeanth @john-science

[albeanth]

Yes, please. 10000% yes.

[keckler]

See #651

[john-science]

Well, you're not the first person to ask for it. So sure, seems like some people would like it.

This new feature would need to be two things:

1. Opt-in: Since it's been a decade and there exist many settings already that don't use this feature, I would say we would need to make this an opt-in solution. Only certain settings could have a "Fail if condition is met" option.
2. Optional. Since there are already thousands of Settings defined in ARMI and downstream, I would want the new solution to not make a breaking change to the API. This should be an optional new argument. For instance, we don't have to add a new argument to every Setting definition in the world. (I think we already have too many mandatory arguments.)

[albeanth]

I'm not following the opt-in vs optional approach you've laid out. Can you elaborate?

[bsculac]

I think they end up being effectively the same. I'm thinking this would be an optional kwarg to the settings validator that would look like failOnNo==False that would then cause not taking the suggested change to fail out of the job if True. This fits the backwards compatibility concern and lets people writing the settings validators decide if the validator should cause a failure.

[john-science]

This feature would need to be both backwards compatible and default to NOT strongly enforced.

That's all.

[jakehader]

@john-science - could it be reasonable to default to failure but then change all settings that do not have a settings validation to have it be false? This might stick out better for future improvements and force new settings to highly consider adding a validator rather than it being an after thought. I think this would result in a large number of changes in a PR, but I'm theory should be easily checkable. Thoughts?