search: clients use 'standard' query interpretation

Created by: rvantonder

Stacked on https://github.com/sourcegraph/sourcegraph/pull/37894.

This switches clients over to use 'standard' query interpretation, which corresponds to the default interpretation in the new V3 version for search. From docstring:

History:

• V3 - default to standard interpretation: Interpret patterns literally, or regular expression when enclosed by /.../ (RFC 675).
• V2 - default to interpreting patterns literally only.
• V1 - default to interpreting patterns as regular expressions.
• None - Anything before 3.9.0 will not pass a version parameter and defaults to V1.

The mechanism for making this switch in the client is to rename (almost) all the instances of SearchPatternType.literal to SearchPatternType.standard in the client. It is the "correct" mechanism to use, since it is effectively source of truth for pattern interpretation because it overrides any version, and pervades all search requests in the client. The ideal state, though, would be to remove the existence of patterntype if/when we can decide there is only ever one query string interpretation. While 'standard' interpretation gets us closer to that goal, it's not a near term goal. The way it gets us closer to this goal is:

• The change effectively deprecates patterntype:literal
• The change makes running regular expressions easy, and so hopefully subsumes the need for patterntype:regexp. To be confident about this change subsuming patterntype:regexp will take some time to propose and evaluate, and also more changes to remove.

About LATEST_VERSION, this is updated to V3 everywhere. But version doesn't effectively "do anything" for our client today (or even client <-> server) interaction, because all those instances get the explicit patterntype (now standard), which overrides the version. But, in a world where we remove patterntype, the fallback to use version will indeed be useful and correct. Right now, the only utility of version is if some outside user/client developed against Sourcegraph some app that uses V1 or V2 and they don't set the patterntype.

Note these behavioral changes with query interactions in the client!

Any new queries created will use patterntype:standard by default unless specified otherwise. This applies to new searches in the client that do not explicitly specify patterntype. This affects at least:

• new searches in the recent searches homepage (@sourcegraph/search-product)
• code monitors, though it needs a small corresponding backend change to honor version (@sourcegraph/search-product)
• notebooks (@sourcegraph/search-product)
• Maybe code insights, please check the affected code in this PR. I'm not clued up entirely about insights creation, but I seem to recall you make users explicitly type out patterntype:regexp (@sourcegraph/code-insights)
• Don't know if/how it affects @sourcegraph/batchers, depends on how the client calls the backend. I suggest updating to patterntype:standard and V3.

Any instances that set search.defaultPatternType in settings is unaffected by this change, since it overrides the default interpretation.

Previously saved queries preserve patterntype:literal. This is true for existing saved queries displayed in the users homepage, codemonitors, and any other client that saves patterntype values in the backend and displays them in the client.

• It's basically impossible to try do any sort of migration here, because maybe it breaks user expectations. The only reasonable/maintainable thing is to move forward as of this release with the new behavior.

• This means if a user clicks a link that does patterntype:literal, they are going to stay in the webapp with patterntype:literal unless they:

  • explicitly add patterntype:standard in the query; OR

  • remove patterntype from the URL; OR

  • toggle regex on/off (toggling will throw them into patterntype:standard after being toggled off)

    • Aside: it would be nice if the user could clear their recent searches to avoid "tricking" themselves into patterntype:literal saved queries, but that's not something I'm putting on my plate. Users have request to delete saved queries irrespective, so this is a good thing to add at some point.

I will deal with src-cli separately.

Test plan

Test run against this change. Manual testing. Still struggling to get main-dry-run to build the server, don't know why!