Prevent the layout field from being removed if overrides exist

This might be critical if LB were stable, so promoting to major.

This is a bug, and would indeed be critical. We have precedent for that for the views/config issue... except this is even worse because that at least had a confirmation form that was hard to read (whereas this one makes a stray mouse click destroy tons of work.)

As a data loss issue, we would make it critical even while LB is in beta. It can remain major while LB is in alpha.

Edit: I mistakenly thought this was the issue for a different problem, wherein the "Revert to defaults" link deletes your layout override with no warning/confirmation/clicking save. Per @tim.plunkett it's a separate issue though, so moving that back to the other issue (there's already a fix for it there now).

I'll test this one and confirm whether it also needs some removal/fix/prevention before beta.

1. Probably we should make the help text not display on that route? For most things it's probably not a big deal for beta, but in the case of this form it kinda distracts from what the form says for an operation that removes data.
    
2. I think we should also tell the user what the consequences of the action are. At the least, something like "Any customized layouts will be permanently deleted." But ideally we'd say something like "13 customized layouts will be deleted."
    
3. Along those lines, unchecking the box is harmless if there are 0 customized layouts. I couldn't think of any examples in core of something that would delete 0 things to use as precedent one way or the other.
    
4. It alarmingly says "Your settings have been saved" before the user confirms. (I verified that the settings have not, in fact, been saved -- the overrides are still enabled -- so it's just that the status message is being displayed prematurely.)
   

Hmm, #4 seems problematic. I would definitely not expect that other values on the page had been saved if I went to a confirmation form and then hit cancel. I'm reluctant to defer that to a followup since it would be a major bug IMO. Tagging for usability review to see if we can get some suggestions.

For #3, how about we tell the user explicitly about currently edited things? E.g.:

13 customized layouts will be permanently deleted, and any unsaved custom layouts will be lost.

Or if there are none, just:

Any unsaved custom layouts will be lost.

Ok, so this new version of the patch sidesteps the whole confirmation issue by simply preventing the unclicking of the form element when overrides exist. As solutions go, this seems like a pretty straight-forward one and I think covers the data loss concern sufficiently. Assuming this passes tests I'm totally on board and saw nothing in the patch that concerned me. Anyone else have push-back on this approach?

Eclipse

+1 for this approach as an intermediate step.

Should we also add a test that the checkbox is again uncheckable when you revert an overridden layout to the default?

I manually tested a few different scenarios and it seems to work fine; no weird/confusing things.

Looks good to me!

Eclipse

Manually tested, screenshots attached, works like it says on the box

Committed 9d81d2c and pushed to 8.6.x

One more down

OK this will work better if I actually post using my account. Retroactively adding credit for Kris and Sam who helped decide the approach with us in Slack. :)

thanks! :-D