Timur query add subclauses; [close #1009]

[coleshaw]

This PR adds in the ability to Timur Query UI to add "subclauses" to each where filter clause (refer to #1009). It looks like:

Functionally, it means there can be additional ::and statements inside of a subquery condition (an ::any or ::every filter). And means you can do queries like:

"Give me all the samples that have (any rna_seq record with EHK > 7 AND compartment == live) AND (any rna_seq record with EHK > 7 AND compartment == myeloid)" to ensure that samples have good quality live and myeloid compartments, but disregard the other compartments.

Note that the backend API already supported this functionality, it just wasn't exposed in the UI, so this PR only contains UI changes.

Also, note that this PR changes the internal filter JSON structure that is sync'd to the URL, so the PR includes a migration path for old, saved query URLs. You can test this by opening up an old query on dev, which should still populate the form correctly.

You can test the subclause query part locally by setting up something like the following:

Then, if we want to see what rna_seq records come from samples with good quality live and myeloid compartments (disregarding other compartments), we can try constructing a query.

The old query UI would have let you construct something like this, and return 0 results (due to the every EHK score >= 8 filter hitting the tcell compartment and saying the sample IPIADR001.T1 doesn't meet the requirements):

With subclauses, we would modify the query and get our expected result:

[coleshaw]

Hm, so I wound up upgrading to CodeMirror6 instead of 5 (I think some underlying dependencies changed), and thus having to also update the View Editor and Manifest Editor.

I'm pretty sure the View Editor behaves as it did before, perhaps with some improvements, like code folding and better "find" within the editor.

I'm pretty sure the Manifest Editor does not do syntax highlighting like it did before, since it's a custom language, though I think it works as an editor ... since this is rarely used, perhaps that is acceptable?

[graft]

There are a few other uses of CodeMirror e.g. in polyphemus and the RevisionHistory pane, possibly on different versions, using a Json schema validator. Dunno if those will break... The manifests seem ok to ignore

[coleshaw]

Ah, that's good to know. That means probably in Vulcan, too. For now, they are different node_modules folders, so probably okay ... if anyone can ever finish #1019, then they would have to be migrated to 6, too. But I think if Revision History uses the standard JSON / Javascript editing features, it would be fairly straightforward to take what's in the View Editor and use that code.

[coleshaw]

Just some context for why I upgraded to CodeMirror6:

sachinraja/rodemirror#139

Basically running into the same issue. The solution was to pin to lower versions of the plugins (which didn't seem to work for me), or just upgrading to 6 ...