* Update the syntax

* Rename filters

* Add repro for #24500

* Skip the repro

* Rename file

* Address comment and fix the syntax

* Improve the test title

* Handle flakiness with geojson java.net.UnknownHostException errors

In CI seems like we are getting errant errors:

```clojure
geojson.clj:62
It validates URLs and files appropriately
http://0xc0000200
expected: (valid? geojson)
  actual: #error {
 :cause "Invalid IP address literal: 0xc0000200"
 :via
 [{:type clojure.lang.ExceptionInfo
   :message "Invalid GeoJSON file location: must either start with http:// or https:// or be a relative path to a file on the classpath. URLs referring to hosts that supply internal hosting metadata are prohibited."
   :data {:status-code 400, :url "http://0xc0000200"}
   :at [metabase.api.geojson$valid_url_QMARK_ invokeStatic "geojson.clj" 62]}
  {:type java.net.UnknownHostException
   :message "0xc0000200"
   :at [java.net.InetAddress getAllByName "InetAddress.java" 1340]}
  {:type java.lang.IllegalArgumentException
   :message "Invalid IP address literal: 0xc0000200"
   :at [sun.net.util.IPAddressUtil validateNumericFormatV4 "IPAddressUtil.java" 150]}]
```

Not clear if this change has a hope of fixing it: if it doesn't resolve
once its possible it is cached somewhere in the network stack, or it
won't resolve if you ask again.

But gonna give it a shot.

Set the property `"networkaddress.cache.negative.ttl"` to `"0"`

> networkaddress.cache.negative.ttl (default: 10)
>    Indicates the caching policy for un-successful name lookups from the name service. The value is specified as an integer to indicate the number of seconds to cache the failure for un-successful lookups.

>    A value of 0 indicates "never cache". A value of -1 indicates "cache forever".

From
https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/net/InetAddress.html
in the hopes that we can try multiple times. Restores the original value
after the test completes so we don't inadvertently change behavior
elsewhere.

If we get an error of java.net.UnknownHostException we try again if we
have attempts remaining. If we get a boolean it means the ip resolution
worked so we can rely on the response (checking if it resolves locally
or not)

* add a delay

* comment out test

* bump snowflake

* Handle Types/TIMESTAMP_WITH_TIMEZONE for snowflake

Snowflake used to return columns of this type as `Types/TIMESTAMP` =
93.

The driver is registered with the legacy stuff

```clojure
(driver/register! :snowflake,
                  :parent #{:sql-jdbc
                            ::sql-jdbc.legacy/use-legacy-classes-for-read-and-set})
```

causing it to hit the following codepath:

```clojure
(defmethod sql-jdbc.execute/read-column-thunk [::use-legacy-classes-for-read-and-set Types/TIMESTAMP]
  [_ ^ResultSet rs _ ^Integer i]
  (fn []
    (when-let [s (.getString rs i)]
      (let [t (u.date/parse s)]
        (log/tracef "(.getString rs i) [TIMESTAMP] -> %s -> %s" (pr-str s) (pr-str t))
        t))))
```

But snowflake now reports the column as `Types/TIMESTAMP_WITH_TIMEZONE`
= 2014 in https://github.com/snowflakedb/snowflake-jdbc/pull/934/files
we no longer hit this string based path for the timestamp with timezone
pathway. Instead it hits

```clojure
(defn- get-object-of-class-thunk [^ResultSet rs, ^long i, ^Class klass]
  ^{:name (format "(.getObject rs %d %s)" i (.getCanonicalName klass))}
  (fn []
    (.getObject rs i klass)))

,,,

(defmethod read-column-thunk [:sql-jdbc Types/TIMESTAMP_WITH_TIMEZONE]
  [_ rs _ i]
  (get-object-of-class-thunk rs i java.time.OffsetDateTime))
```

And `(.getObject ...)` blows up with an unsupported exception.

```java
  // @Override
  public <T> T getObject(int columnIndex, Class<T> type) throws SQLException {
    logger.debug("public <T> T getObject(int columnIndex,Class<T> type)", false);

    throw new SnowflakeLoggedFeatureNotSupportedException(session);
  }
```

There seem to be some `getTimetamp` methods on the
`SnowflakeBaseResultSet` that we could call but for now I'm just
grabbing the string and we'll parse on our side.

One style note, it is not quite clear to me if this should follow the
pattern established in `snowflake.clj` driver of setting `defmethod
sql-jdbc.execute/read-column-thunk [:snowflake
Types/TIMESTAMP_WITH_TIMEZONE]` or if it should follow the legacy
pattern of `defmethod sql-jdbc.execute/read-column-thunk
[::use-legacy-classes-for-read-and-set Types/TIMESTAMP]`. It seems like
almost either would be fine. Just depends on whether other legacy
drivers might like this fix which seems possible?

* Move support JS files inline with the test

* Fix and unskip repro for 12720

* Update syntax in 12985 repro

- Removed unnecessary dashboard filter
- Simplify repros

* Use the existing test to reproduce 13960

* Add repro for #16112

* Remove unnecessary intercepts

* Merge 13150, 15689, 15695 and 16103 together

* Use the existing test to reproduce 17139

* Move repro for 6660 to date filters file

These snippets contain raw `Database`, `Table`, and `Field` IDs, and so are not portable. This PR proves out the concept for `Card.dataset_query`, paving the way for the others in a follow-up PR.

* make search visible

* update Modal title

* Fixing null error when value is null and isCustom is true

* PR Feedback

* exception for none and block

* add howon's test

See https://github.com/metabase/metabase/pull/23976#issuecomment-1191290882

* open urls with the site-url origin in the same tab

* revoew

Enforce bigint for all int fields derived from JSON instead of doing more complete refactor (#24494)

Pursuant to #22732. Should basically eliminate it with prejudice by saying that any int should fit bigints in our point of view in postgres.

* Bump SSHd lib -> 2.9.0 [master]

* Remove old comment

* correct format datetime property for snowplow

* some docs and comments

- https://github.com/metabase/metabase/runs/7613584093?check_suite_focus=true
- https://github.com/metabase/metabase/runs/7613615892?check_suite_focus=true
- https://github.com/metabase/metabase/runs/7613623878?check_suite_focus=true

* dont tokenize single input values

* remove border-dark

* update border-dark references

* Remove duplicated test

We're already testing `between` number dashboard filter in:
- frontend/test/metabase/scenarios/dashboard-filters/dashboard-filters-number.cy.spec.js
- frontend/test/metabase/scenarios/dashboard-filters/dashboard-filters-sql-number.cy.spec.js

* Speed test up using API where possible

* Remove another duplicate

This flow is already covered in:
- frontend/test/metabase/scenarios/dashboard-filters/dashboard-filters-sql-required-field-filter.cy.spec.js
- frontend/test/metabase/scenarios/dashboard-filters/dashboard-filters-sql-required-simple-filter.cy.spec.js

* Merge three logical units into one test

Reference issue #17933 and explicitly mark it as reproduced.

* Merge repros for 9299 and 16181 together

* Refactor permissions test

* Rename and put TODO note for 18113