* Fix Snowflake filtering on date for `timestamp with time zone` columns

* Snowflake should just generate raw SQL for literals

* Go ahead and fix other Snowflake stuff and reenable a bunch of disabled tests

* Snowflake test fixes 

* Minor test improvements

* Fix Redshift and Vertica as well.

* Address PR feedback

* Store Parameter Values Set by User on a per-user basis

This is a WIP for #28181 and the notion doc:

https://www.notion.so/metabase/Tech-Maintain-user-level-state-in-dashboards-for-filters-fc16909a3216482f896934dd94b54f9a

Still to do:

- [ ] validate the table/model design
- [ ] hook up the endpoints mentioned in the doc (2 in api/dashboard)
- [ ] return the user specific parameter values on /api/dashboard/:dashboardID endpoints
- [ ] write a few tests to capture the intent of this feature

* Accidentally deleted a digit in the change ID timestamp

* first pass at writing user param values to the db.

It's in a doseq here which is probably not the correct way to go yet, but it's a step in the right direction.

* Hydrate dashboard response with `:last_used_param_values` key

If the user has previously set a parameter's value, it will show up in the map under that parameter id.

If the user has no parameter value set, that entry will be 'null'.

* Use proper fn name

* Only save or retreive user params if there's a current user id

* Add model to necessary lists

* Only run query when there are parameter ids to run it with

* Add a test to confirm that last_used_param_values works

* Add models test namespace for CRUD test

* The hydration is checked in the dashboard api test already

* Remove `dataset_duration` from MetabaseApi

* Remove unused endpoint

* Revert "Store fields used in MBQL cards in QueryField (#41821)"

This reverts commit 0da81005.

* comment out test

Previously they could only be added to the query with `Lib.extract`, but
this returns the expression the extract would add.

* Fix add-alias-info matching for nominal field literal refs

* Minor cleanup

* Minimize diff

* A bit more cleanup

* Cumulative aggregations w/ multiple breakouts should reset counts (#2862)

* Update dox

* Do the nesting FIRST before adding alias info.

* Remove unused

* FE for Offset()

* Cleanup stray code

* Prettier

* Kondo

* Test fixes 

* Better error message when no breakout

* Support offset as an expression with no breakouts. Still require an ORDER BY tho.

* Fix most stuff

* Hack city??????

* Revert nest-query changes and disable the offset-no-breakout test for now.

* Appease TypeScript

* Test fix 

* Oracle & MySQL test fixes

* Test fixes 

* Remove maxWorkers for FE unit tests

* Missing sentence for NQA documentation

* Add a test for optional field filter parsing

Co-authored-by: Emmad Usmani <emmadusmani@berkeley.edu>
Co-authored-by: Adam James <adam.vermeer2@gmail.com>
Co-authored-by: Mark Bastian <markbastian@gmail.com>
Co-authored-by: Jesse Devaney <22608765+JesseSDevaney@users.noreply.github.com>
Co-authored-by: Anton Kulyk <kuliks.anton@gmail.com>

* Add `collection.effective_ancestors` to search

Fixes #41909

The ultimate goal here is to be able to display a UI that showed the entire (effective) path to each collection.

This was a bit more painful than I'd hoped. The primary issue is that we
tied two things together:

- scoring results

- "serializing" results (really, partially serializing results, because
we do more work to shape the data later)

Why is this a problem? The `top-scorers` function took a transducer and
returned the *serialized* top scorers. Later, when we need to operate
on *all* the top results (in this case, to collect all the collection
IDs and names that we know of), we're looking at the serialized results.

In our case, we needed some data (collection location) that wasn't
included after serialization. We could add it, of course, but it's
frustrating to need to change the API of what data is *returned* from
the endpoint for purely internal purposes (changing the data available
during *processing*).

I ended up pulling serialization out of the scoring function. At some
point down the road, we should go ahead and move the `serialize`
function out of the `search.scoring` namespace entirely - there's really
no reason for it to belong there as far as I can tell.

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.

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.

Also add the replace-names fn, which is a simple pass-through to Macaw #modularity

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

This reverts commit f5bd6344.

Pretty much does what it says on the tin.

It has a slightly different API shape. We're not using it right this
minute, but we're about to and it seemed nice to separate this out into
its own PR

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>