The new expressions `:month-name`, `:quarter-name` and `:day-name`
return the (user localized) names for these units, given the
corresponding number.

For example, 4 yields `"Apr"`, `"Q4"` or `"Wednesday"` respectively.

The `column-extract` drill uses these new expressions, rather than
generating its own `:case` clauses for them.

Note that `:day-of-week` and `:month-of-year` are tricky cases for i18n, but there are tests that exercise them thoroughly.

Part of the follow-up for Extract Column epic #38964.

* Fix the flake in add-required-filter-if-needed-test due to field order

* /s/oredered-filter/ordered-filter

Column extractions are "canned" expressions based on a column's
type. For example, we might extract the weekday from a temporal column,
or the domain from an email or URL column.

This logic already existed inside the `column-extract` drill; this pulls
it out as a top-level concept, since extractions are also being
integrated into the notebook editor apart from drills.

Part of the follow-up for Extract Column epic #38964.

(It's coming back in similar form, but EE-only)

This reverts commit f5bd6344.

Pretty much does what it says on the tin.

Co-authored-by: Chris Truter <crisptrutski@users.noreply.github.com>

* Dates Binned by Week Export Formatting Matches App

Fixes: #41492

Before, the dates binned by week would be formatted as follows in CSV and JSON exports:

`Week 1 - 2024`

But that doesn't match the App's format of a Date Range:

`January 1, 2024 - January 7, 2024`

So, now the exports will apply formatting in this same way.

Note that a second bug (#41616) exists on the Frontend preventing the column formatting being applied in the app. This is
frontend only, and the csv and json exports will match the column formatting settings (eg. abbreviated dates and
alternative separators will be used in the export).

* add test and change default week style

* Week format test change

* also fix incorrect :hour formatting

* [tech debt] Stop using ms/BooleanString and only use ms/BooleanValue

ms/BooleanString will coerce to a string, and we should probably get rid of it and only ever use ms/BooleanValue which will always coerce to a boolean
We want the coercion layer to give us values that are helpful, and true is more helpful than "true".
So we should remove ms/BooleanString and calls to parseBoolean

* Remove ms/BooleanString usage in api/native_query_snippet.clj

* Remove test case related to ms/BooleanString

* Remove the BooleanString schema def as no longer used

These functions are implemented with hairy regular expressions, and
it's more user-friendly and future-proof to name those functions in MBQL
rather than baking the `regexextract` and regex into the user's query.

It lets us evolve the regexes in the future if we detect a bug, and it
improves the UX since the user sees a meaningful function instead of

    regexextract([My URL Column], "(?<=[@\.])(?!www\.)[^@\.]+(?=\.[^@\.]{1,3}\.[^@\.]+$|\.[^@\.]+$)")

Also refactors the regexes somewhat so that they work for emails as well as URLs, and there's always just one layer of `:regex-match-first`.
Previously this was separated into two steps: URL or email to host, and host to (sub)domain.

Part of the follow-up for Extract Column epic #38964.

Co-authored-by: Noah Moss <noahbmoss@gmail.com>
Co-authored-by: Noah Moss <32746338+noahmoss@users.noreply.github.com>
Co-authored-by: Nick Fitzpatrick <nick@metabase.com>
Co-authored-by: John Swanson <john.swanson@metabase.com>
Co-authored-by: Sloan Sparger <sloansparger@users.noreply.github.com>
Co-authored-by: Sloan Sparger <sloansparger@gmail.com>

The filters for _numeric_ PK and FK filters are slightly different than a general numeric column. That's fine for numeric keys, but with string keys that same set of numeric filters was being returned, and then the ones for strings were removed. That left only `Is` and `Is Not` for a string PK or FK.

This PR allows more flexibility in filtering by string PKs and FKs, by checking the base type of the column and using the right set of filters for the type of key.

Closes #40665.

* FeedbackModal for the Embedding Homepage

* add source and change to correct endpoint

* fix tests, adding await and fixing endpoint

* use toEqual to also check for the source

* addresses PR feedback

* button becomes Send when email is written

* make 'comments' optional, trim inputs and refactor tests

* product-feedback endpoint (#40974)

* mvp of the proxy endpoint for the product feedback

* cleanup and fixes

* email :string -> ms/NonBlankString

* revert my solution

* Dan diff file

* makes fields other than source optional

* don't use default value in dev, to not spam the prod endpoint

* change from setting to function for product-feedback-url, as it's not meant to be changed by end users

* changed endpoint as per https://metaboat.slack.com/archives/C010ZSXQY87/p1712918951362979?thread_ts=1704910781.153589&cid=C010ZSXQY87



* fix wrong dismiss reason sent for 'I'm not interested right now'

* Update frontend/src/metabase/home/components/EmbedHomepage/EmbedHomepage.tsx

Co-authored-by: Mahatthana (Kelvin) Nomsawadi <me@bboykelvin.dev>

* renamed field: feedback -> comment

---------

Co-authored-by: Mahatthana (Kelvin) Nomsawadi <me@bboykelvin.dev>

This reverts commit e0e4ade0.

Co-authored-by: Noah Moss <noahbmoss@gmail.com>
Co-authored-by: Noah Moss <32746338+noahmoss@users.noreply.github.com>
Co-authored-by: Nick Fitzpatrick <nick@metabase.com>
Co-authored-by: John Swanson <john.swanson@metabase.com>
Co-authored-by: Sloan Sparger <sloansparger@users.noreply.github.com>
Co-authored-by: Sloan Sparger <sloansparger@gmail.com>

Not all drivers support regular expressions. Don't return the
Column Extractions for URL -> (sub)domain and email -> domain unless the
database can support the regular expression matches.

Part of the follow-up for Extract Column epic #38964.

This improves our Malli performance substantially! Many of our code paths were calling vanilla `malli.core/validate` or `malli.core/explain`; these redo the (possibly expensive) compilation of the schema into a validator or explainer for every call.

We should use the caching versions in `metabase.util.malli.registry` everywhere, and our runtime performance will be much improved.

However when I started using these cached versions, I found that the memory use was growing out of control. Eventually I tracked this down to `:fn` schemas. Functions are only comparable by pointer equality, so they make poor cache keys. `(fn ...)` or `comp` calls in a schema on a `mu/defn` function **get re-created for every call of the `mu/defn`'d function**! That's a big time sink recompiling the schemas if we're *not* caching, and a huge memory sink if we *are* caching!

This PR pulls every such schema I could find out into a `def` so it uses the same closure and is cacheable. I'd like to automate that in some part of the Malli pipeline, or maybe a linter rule, but I haven't found a good way to do it yet.

Part of #39946.