Manually-added Query Tags in "Query Settings" are Lost when Changing Override Status of Query Options for any Display

Problem/Motivation

If a view has custom "Query Tags" set on any display of the view (including the "Master" display), those tags will be lost if a site builder opts to override Query options for a particular display of the view OR opts to reset the Query options for the display back to the options from its Master display.

Steps to reproduce

1. Create a new view.
2. Add a "Page" display to the view.
3. While in the "Page" display, expand "Advanced", and click on the "Settings" link next to "Query settings".
4. Enter the word "test" into the "Query Tags" box.
5. Click the "Apply (all displays)" button.
6. Add a "Block" display to the view.
7. While in the "Block" display, expand "Advanced", and click on the "Settings" link next to "Query settings".
8. Change "For" from "All displays" to "This block (override)".
9. Add the word "test_two" into the "Query Tags" box (so it reads "test,test_two").
10. Click the "Apply (this display)" button.
11. While still in the "Block" display, click on the "Settings" link next to "Query settings" again.
12. Observe what's in the "Query tags" box.
13. Change "For" from "This block (override)" to "All displays (except overridden)".
14. Enter "test" in the "Query Tags" box.
15. Click the "Apply (all displays)" button.
16. Switch back to the "Page" display.
17. Click on the "Settings" link next to "Query settings".
18. Observe what's in the "Query tags" box.

At steps 12 and 18, the query tags will have been completely lost. If the user edits the values a second time and saves, they will persist; this issue only appears to crop up when the display is being toggled to override or back to matching Master. The data loss at step 18 is much worse than that of step 12 because it affects the "Master" display's copy of the query tags, which would affect all views that are not overriding Master.

I've marked this issue as Major because:

• This leads to data loss (in the form of losing the query tags).
• The issue is subtle, to the point that a site builder might not realize it's even happened until much later.
• Query tags can be used for access control or any number of functions, which could lead to information disclosure or other site-wide vulnerabilities depending upon the nature of the view being edited.

Proposed resolution

Stepping through this in the debugger, when the "For" drop-down is changed from one mode to another, \Drupal\views\Plugin\views\query\Sql::submitOptionsForm() gets invoked twice. The first time, it's invoked and the form has the value of interest. The next time, the value isn't present in the form where expected but the query options in the form state do have the right tags set; sadly, during that second call -- since the form doesn't contain the tags -- the tags get obliterated from the query options since the code doesn't find the options in the form.

It looks like this happens in \Drupal\views_ui\ViewUI::standardSubmit(). The code there will invoke each submit handler twice when toggling modes; it invokes the handler once for the reset and then again normally; that feels a bit odd. But -- at least with respect to this particular issue -- we could probably cheat by checking if the target value in the form state is already an array before proceeding.

I'll take a stab at a crude patch for that issue but would appreciate some help from the Views team on getting a better solution for this.

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet