Fix flaky `rotate-encryption-key!-test`

Bind a temporary site locale when running the test, and disable the settings cache

Now, a full explanation of what was making the test flaky, for posterity:

When this test runs, it first tries to create a blank app DB.  This is either postgres, h2, or mysql, depending on the driver under test, which is slightly confusing, but anyway...

In order to populate all the app DB tables (since the "real" app DB has already been initialized at this point to even run the test), it first rebinds the appropriate dynamic vars for the db type, spec, connection, etc. and then loads a test fixture H2 file into the app DB.  This h2 test fixture file, evidently, contains all the current app DB tables, etc.

When initializing the app DB from H2 (in `metabase.cmd.copy/copy!`), the code needs to internationalize certain loading message strings.  And in order to internationalize messages, it has to look up the current site locale, which is itself an application setting, which of course comes from the setting entity table.

For the "regular" blank app DB scenario (i.e. when Metabase first starts with a blank app DB), there is some code in the `metabase.util.i18n.impl` namespace to handle this chicken and egg problem (basically, defaulting to "en" if it can't be loaded from the app DB because there is no app DB yet).  But after this tricky process finishes, that temporary, hacked lookup is replaced by the real one (since now, the app DB exists and the locale can just be loaded normally).

For the purpose of our test, that is the problem.  That state (which swaps out the `site-locale-from-setting` fn) has already run (remember, we have already initialized the app DB to even run this test in the first place, and now we are swapping in a temporary one).  So the call to load the site locate from the settings table (which is needed to print the loading message to initialize this temp app DB) fails, and hence the test fails.

Now, the reason this test was flaky, instead of just always failing, is because of the settings cache.  If the site locale had been loaded anywhere within some short time frame before this test needs to load it, to print init messages, then it succeeds!  But that doesn't always end up happening, of course, since it's effectively a race condition (setting cache expiration versus test execution timing).

Currently it only displays JS errors. Now, it still displays JS errors first but if there's a query error and no JS error it'll display the query error

* refactor getMappingsByParameter

* handle dashcard.series and dashcard.parameter_mappings being undefined

* pull out getMapping fn from getMappings

* rmv hasDisjointValueSets code + ui warning

* Expand `openNativeEditor` helper for use with multiple databases

* Move #18069 to custom column reproductions

Co-authored-by: Nemanja <31325167+nemanjaglumac@users.noreply.github.com>

* Relativize links when emitting html from md in pulse/subscriptions

Helpful links:
- https://awesomeopensource.com/project/vsch/flexmark-java
- https://github.com/vsch/flexmark-java/blob/master/flexmark-java-samples/src/com/vladsch/flexmark/java/samples/PegdownCustomLinkResolverOptions.java
- https://github.com/vsch/flexmark-java/blob/8a881b73109a287b5f202e2e1fc9f9c497d5eecf/flexmark/src/main/java/com/vladsch/flexmark/html/HtmlRenderer.java#L433
- https://github.com/vsch/flexmark-java/blob/8a881b73109a287b5f202e2e1fc9f9c497d5eecf/flexmark/src/main/java/com/vladsch/flexmark/html/renderer/ResolvedLink.java#L10

This was a pain in the ass. I had been looking for a way to just easily
traverse the ast, but this might cause problems since there are spans
and text positions everywhere. So i looked at how to change the
parser. Everything is so difficult to change. Luckily there was a
built-in way to do this with link resolvers, found in a github issue
https://github.com/vsch/flexmark-java/issues/308 . And ideally this
would be done in the parser but it seems to be done in the html
emitter.

https://github.com/vsch/flexmark-java/blob/master/flexmark-java-samples/src/com/vladsch/flexmark/java/samples/CustomLinkResolverSample.java

And then I got turned around on what is relative or not. What happens if
you do something seemingly sane like:

```markdown
[a link to google](www.google.com)
```

This is apparently a relative link since it lacks a protocol. And our
`resolve-uri` code treats it as such:

```clojure
markdown=> (resolve-uri "www.google.com")
"http://localhost:3000www.google.com"
markdown=>
```

This seems strange to me but is also the behavior on gist.github.com:
https://gist.github.com/dpsutton/412502ffa89186487e41885855dfa781 has a
link to https://gist.github.com/dpsutton/www.google.com

In all, trying to figure out this object oriented factory mess i had 24
tabs open to the source of NodeVisitor, NodeVisitorBase,
AstActionHandler, VisitHandler, ParserExtension,
NodePostProcessorFactory, etc. It was truly unpleasant.

* Remove errant require of mb.util.urls

* Ensure the site setting always has a slash when resolving relative

The URI class will do some wonky things. Sometimes it feels structural,
but it can also just feel like it is combining strings willy nilly.

```clojure
(.. (URI. "http://example.com") (resolve "www.google.com") toString)
"http://example.comwww.google.com"
```

So ensure that there is a final trailing slash

We had a few users who reported that they couldn't connect, this simple lineshould fix that

This is more of a quick workaround (read: hack) until we have a better
parsing infrastructure.

The idea is to have an extra argument to contains/startsWith/endsWith,
which will be "case-insensitive" if the comparison is to be carred out
by ignoring the case. If this extra argument wasn't specified, then
it'll be assumed that the case-sensitive comparison is intended.

IOW, this MBQL `["contains", X, Y`] or `["contains", X, Y,
{case-sensitive: true}]` will be equivalent to the user-visible custom
expression `CONTAINS(X)`.

Meanwhile, MBQL `["contains", X, Y, {case-sensitive: false}]`
will be mapped to the user-visible custom expresson
`CONTAINS(X, Y, "case-insensitive")`.

With this, we achieve a lossless conversion for 3 string functions
(contains, startsWith, endsWith) when involving case-sensitivity.

* Add MB_SEND_EMAIL_ON_FIRST_LOGIN_FROM_NEW_DEVICE

* Update docs/operations-guide/environment-variables.md

Co-authored-by: flamber <1447303+flamber@users.noreply.github.com>

Co-authored-by: flamber <1447303+flamber@users.noreply.github.com>

* Don't render bar charts are sparklines

https://github.com/metabase/metabase/issues/18352

A simple select `SELECT 'a', 1 UNION ALL SELECT 'b', 2` would trigger as
a sparkline and blow up when comparing. There are two issues:
- don't render tables as a sparkline even if it only has two columns
- don't compare things that aren't comparable.

this solves the first issue, ensuring that tables aren't matched as
sparklines

* Sparkline should only compare comparable values

Check that the columns are temporal or numeric before comparing them. It
is only to optionally reverse the order of the results which seems
questionable in itself, but we can at least check that they are
comparable before attempting to

* Ensure tests render as sparklines

default was a :table and that adds csv attachments which throw off our
tests

* unskip repro

* remove unnecessary extra line

Input:    12345.65432
Expected: 12346
Actual:   12346.

We were unconditionally adding "." (repeat decimals "0") to the base
formatting string. Obviously when the decimals are 0, we are appending
"." to the base format string

* Unskip the repro test

* Fix duplicate variable calc

* Fix schema update with blank tables state