* add dummy workflow clones to make originals required

* review

* only default to contains operator for long text fields

* fix calculating labels for stacked charts

* fix related 17205

* update waterfall spec

The jar worked fine except when trying to add partner jars (exasol,
starburst, etc)

```shell
❯ java --version
openjdk 11.0.14.1 2022-02-08
OpenJDK Runtime Environment Temurin-11.0.14.1+1 (build 11.0.14.1+1)
OpenJDK 64-Bit Server VM Temurin-11.0.14.1+1 (build 11.0.14.1+1, mixed mode)

/tmp/j via  v11.0.14.1 on   metabase-query
❯ jar uf 0.44.0-RC1.jar modules/*.jar
java.lang.module.InvalidModuleDescriptorException: Unsupported major.minor version 61.0
	at java.base/jdk.internal.module.ModuleInfo.invalidModuleDescriptor(ModuleInfo.java:1091)
	at java.base/jdk.internal.module.ModuleInfo.doRead(ModuleInfo.java:195)
	at java.base/jdk.internal.module.ModuleInfo.read(ModuleInfo.java:147)
	at java.base/java.lang.module.ModuleDescriptor.read(ModuleDescriptor.java:2553)
	at jdk.jartool/sun.tools.jar.Main.addExtendedModuleAttributes(Main.java:2083)
	at jdk.jartool/sun.tools.jar.Main.update(Main.java:1017)
	at jdk.jartool/sun.tools.jar.Main.run(Main.java:366)
	at jdk.jartool/sun.tools.jar.Main.main(Main.java:1680)
```

The 22.1.0 graal/js requires a similarly versioned graal/truffle which
is multi-release but includes on versions/11 class files. The upgraded
one includes versions/17 and since our uberjar is not multi-release,
when running it on java 11 it rejects handling class version 61.0 (java
17) files. If the uberjar were multi-release it would know to select the
versions it wanted.

* revert #23658

* keep the migration to add native_query_snippet.template_tag, add a new migration to drop it

* Remove snippet parameter support in fully parametrized check

Co-authored-by: Tamás Benkő <tamas@metabase.com>

* Ensure uploaded secrets are stable

Fixes: https://github.com/metabase/metabase/issues/23034

Background:
Uploaded secrets are stored as bytes in our application db since cloud
doesn't have a filesystem. To make db connections we stuff them into
temporary files and use those files.

We also are constantly watching for db detail changes so we can
recompose the connection pool. Each time you call
`db->pooled-connection-spec` we check if the hash of the connection spec
has changed and recompose the pool if it has.

Problem:
These uploaded files have temporary files and we make new temp files
each time we call `db->pooled-connection-spec`. So the hashes always
appear different:

```clojure
connection=> (= x y)
true
connection=> (take 2
                   (clojure.data/diff (connection-details->spec :postgres (:details x))
                                      (connection-details->spec :postgres (:details y))))
({:sslkey
  #object[java.io.File 0x141b0f09 "/var/folders/1d/3ns5s1gs7xjgb09bh1yb6wpc0000gn/T/metabase-secret_1388256635324085910.tmp"],
  :sslrootcert
  #object[java.io.File 0x6f443fac "/var/folders/1d/3ns5s1gs7xjgb09bh1yb6wpc0000gn/T/metabase-secret_9248342447139746747.tmp"],
  :sslcert
  #object[java.io.File 0xbb13300 "/var/folders/1d/3ns5s1gs7xjgb09bh1yb6wpc0000gn/T/metabase-secret_17076432929457451876.tmp"]}
 {:sslkey
  #object[java.io.File 0x6fbb3b7b "/var/folders/1d/3ns5s1gs7xjgb09bh1yb6wpc0000gn/T/metabase-secret_18336254363340056265.tmp"],
  :sslrootcert
  #object[java.io.File 0x6ba4c390 "/var/folders/1d/3ns5s1gs7xjgb09bh1yb6wpc0000gn/T/metabase-secret_11775804023700307206.tmp"],
  :sslcert
  #object[java.io.File 0x320184a0
  "/var/folders/1d/3ns5s1gs7xjgb09bh1yb6wpc0000gn/T/metabase-secret_10098480793225259237.tmp"]})
```

And this is quite a problem: each time we get a db connection we are
making a new file, putting the contents of the secret in it, and then
considering the pool stale, recomposing it, starting our query. And if
you are on a dashboard, each card will kill the pool of the previously
running cards.

This behavior does not happen with the local-file path because the
secret is actually the filepath and we load that. So the file returned
is always the same. It's only for the uploaded bits that we dump into a
temp file (each time).

Solution:
Let's memoize the temp file created by the secret. We cannot use the
secret as the key though because the secret can (always?) includes a
byte array:

```clojure
connection-test=> (hash {:x (.getBytes "hi")})
1771366777
connection-test=> (hash {:x (.getBytes "hi")})
-709002180
```

So we need to come up with a stable key. I'm using `value->string` here,
falling back to `(gensym)` because `value->string` doesn't always return
a value due to its cond.

```clojure
(defn value->string
  "Returns the value of the given `secret` as a String.  `secret` can be a Secret model object, or a
  secret-map (i.e. return value from `db-details-prop->secret-map`)."
  {:added "0.42.0"}
  ^String [{:keys [value] :as _secret}]
  (cond (string? value)
        value
        (bytes? value)
        (String. ^bytes value StandardCharsets/UTF_8)))
```

Why did this bug come up recently?
[pull/21604](https://github.com/metabase/metabase/pull/21604) gives some
light. That changed
`(hash details)` -> `(hash (connection-details->spec driver details))`

with the message

> also made some tweaks so the SQL JDBC driver connection pool cache is
> invalidated when the (unpooled) JDBC spec returned by
> connection-details->spec changes, rather than when the details map
> itself changes. This means that changes to other things outside of
> connection details that affect the JDBC connection parameters, for
> example the report-timezone or start-of-week Settings will now properly
> result in the connection pool cache being flushed

So we want to continue to hash the db spec but ensure that the spec is
stable.

* typehint the memoized var with ^java.io.File

* Switch memoization key from String to vector of bytes

Copying comment from Github:

When you upload a sequence of bytes as a secret, we want to put them in
a file once and only once and always reuse that temporary file. We will
eventually hash the whole connection spec but I don't care about
collisions there. It's only given the same sequence of bytes, you should
always get back the exact same temporary file that has been created.

So i'm making a function `f: Secret -> file` that given the same Secret
always returns the exact same file. This was not the case before
this. Each uploaded secret would return a new temporary file with the
contents of the secret each time you got its value. So you would end up
with 35 temporary files each with the same key in it.

An easy way to get this guarantee is to memoize the function. But the
secret itself isn't a good key to memoize against because it contains a
byte array.

If the memoization key is the byte-array itself, this will fail because
arrays have reference identity:

```clojure
user=> (= (.getBytes "hi") (.getBytes "hi"))
false
```

So each time we load the same secret from the database we get a new byte
array, ask for its temp file and get a different temp file each time.

This means that memoization cannot be driven off of the byte array. But
one way to gain this back quickly is just stuff those bytes into a
string, because strings compare on value not identity. This is what is
currently in the PR (before this change). I was banking on the
assumption that Strings are just opaque sequences of bytes that will
compare byte by byte, regardless of whether those bytes make sense.

But you've pointed out a good point that maybe that is flirting with
undefined behavior. If we use the hash of the contents of the byte array
as the memoization key with (j.u.Arrays/hashCode array), then we open
ourselves up the (albeit rare) case that two distinct secret values hash
to the same value. This sounds really bad. Two distinct secrets (think
two ssh keys) but both would map to only one file containing a single
ssh key.

An easy way to have the value semantics we want for the memoization is
just to call (vec array) on the byte array and use this sequence of
bytes as the memoization key. Clojure vectors compare by value not
reference. So two secrets would return the same file if and only if the
sequence of bytes are identical, in which case we would expect the files
to be identical. This gives me the same guarantee that I was wanting
from the String behavior I used initially without entwining this with
charsets, utf8, etc.

* hot fix for the wrong api-documentation

* resolve the reflection warning

Pursuant to #24214. Previously MySQL JSON spunout fields didn't work when the individual fields had heterogeneous contents because type information was missing, unlike where type information was provided in Postgres JSON fields. Now they are provided, along with a refactor to not use reify which was used in Postgres JSON fields because the type operator was really annoying otherwise to add (MySQL type cast is a function qua function).

This change makes sure that false as the default value in a case statement is not ignored.

* Remove the `Dependency` model code

* Appease the namespace linter again.

* smarter hashing for advanced fieldvalues

* saving some db calls

* updates some docs and remove an unecessary macro

* Set a timeout for `isValidTimeout`

When using ssh with db connections:
Our theory is that the db connection has no idea that it sits on top of
an ssh connection. And if the ssh connection dies (ie, `show full
processlist` and then `kill <id>` from that list in mysql) the db
connection has no idea it is dead. "It" is valid but its ssh transport
is dead.

> It is possible to customize how c3p0's DefaultConnectionTester tests
> when no preferredTestQuery or automaticTestTable are available. Please
> see Configuring DefaultConnectionTester.isValidTimeout and Configuring
> DefaultConnectionTester.QuerylessTestRunner.

from https://www.mchange.com/projects/c3p0/#automaticTestTable

> Configuring DefaultConnectionTester.isValidTimeout

> Under circumstances when the JDBC 4+ isValid(...) test will be used by
> c3p0's built in DefaultConnectionTester (see below), by default the test
> will never time out. If you would the test to timeout and fail, set the
> following key

>    com.mchange.v2.c3p0.impl.DefaultConnectionTester.isValidTimeout

> to the desired timeout, in seconds.

https://www.mchange.com/projects/c3p0/#configuring_dctivt

* Bump to 6 seconds. Worried 3 might be a bit too quick

* responsive text sizes and spacing

* responsive height and icon size

* responsive tab and input sizes

* use styled component for field icons

Co-authored-by: Ryan Laurie <iethree@gmail.com>

* Add a check to PUT /user/:id to disallow name edits if an SSO user

* Clean up After SAML SSO tests

The `:sso_source` key is set for the Rasta user in some SAML tests, but is expeted to be nil in subsequent tests, so
we clean up in the SAML test ns.

* Add a test to ensure SSO user names can't be changed via API

* Missed a change I had made while adjusting tests

* valid-name-update? take 1 name, to allow better error messages

Let's the user know that first or last name is the cause of a problem, rather than just 'names'.

* Remove unneeded thread macro

* Use partial=

* slight change to local fn for reusability

* Remove `isEditing` from QB state type

* Remove `isEditing` from `updateQuestion` action

* Remove `isEditing` from `setTemplateTag` action

* Remove `isEditing` from QB state code