I misunderstood the desired behavior when I implemented this before. We
only want the limit to apply when the `add-default-userland-constraints`
middleware is applied to the query, not when we're downloading the data
directly.

This is a bit of a rat's nest. If there's a better way to approach the
problem, I'd be happy to hear it. I added documentation for the odd approach
as much as possible.

The main difficulty is that the userland middleware does not have access
to db-local settings. So if we want db-local settings to apply only to
userland, we have to hack our way around it.

The solution here is to divide the userland middleware into two parts:

- the actually-userland bit, which just marks the query as needing
default limits, and

- a middleware inserted deeper in the middleware stack (just before we
actually apply limits) that actually calculates those limits and
attaches them to the query.

* Cast to timestamp before truncating

The shift according to the timezone after the truncation can produce values not at the beginning of the truncation
period.

* Separate handling of time and date inputs

* Add test reproducing issue #37065

It's hard for Snyk to understand which version will be used in the end,
so it complains.

* Fix Snowflake sync not returning all schemas regression in 48+

* Fix extra whitespace

* Better DB name

* Improved test

* Add timezone to database metadata

* Use UTC as _user timezone_ for snowflake driver

* Use user timezone as db-default-timezone

* Update oracles unprepare-value to handle Z UTC

* Update `driver/db-default-timezone :h2` to use jvm timezone

* Update containers timezone to match instance timezone and tests

* Update modules/drivers/oracle/src/metabase/driver/oracle.clj

Co-authored-by: metamben <103100869+metamben@users.noreply.github.com>

* Make unprepare symmetric for offset and zoned datetime

---------

Co-authored-by: metamben <103100869+metamben@users.noreply.github.com>

* fix sql server dfeault

* address comments

* Add test

* Use atom to track next alias index

* Update testing string

Co-authored-by: metamben <103100869+metamben@users.noreply.github.com>

* Use volatile instead of atom for index tracking

---------

Co-authored-by: metamben <103100869+metamben@users.noreply.github.com>

* Match SparkSQL database-type case insensitive

* Use lower-case-en to match SparkSQL database-type

---------

Co-authored-by: Bas Beelen <bas.beelen@channable.com>
Co-authored-by: lbrdnk <lbrdnk@users.noreply.github.com>

* Add remove remark functionality to athena

* Update frontend/src/metabase/databases/constants.tsx

Co-authored-by: metamben <103100869+metamben@users.noreply.github.com>

* Update comment

---------

Co-authored-by: metamben <103100869+metamben@users.noreply.github.com>

* Dont retry cancelled queries on Bigquery

* Add test coverage for ignoring retry on cancellation

* Cancel running BQ jobs on cancellation request

* Fix indentation

* Throw exception with cancelled flag

* Join lines

* Change unique query string

* Fix parentheses

Co-authored-by: metamben <103100869+metamben@users.noreply.github.com>

* Change e to ex-data

* Set namespace explictly in mock exception

* Rename query identification string

* Use bigquery namespace

Co-authored-by: metamben <103100869+metamben@users.noreply.github.com>

* Remove query cancellation code

* Remove comment

---------

Co-authored-by: metamben <103100869+metamben@users.noreply.github.com>

@jeff-bruemmer pointed out that these names are redundant in #36723.

Theoretically one could argue that the settings aren't actually setting the "query row limit" - when you make a new
question, you can enter whatever limit you like. Instead, they're setting the *maximum* possible "query row limit."

That said, applying two limits is the same as applying the minimum of two limits, so calling it a "query row limit"
makes sense too, and might be more clear.

* Move sample-dataset.edn into test-data.edn

Replace (mt/dataset sample-dataset with (mt/dataset test-data

Replace more references to sample-dataset with test-data

Fix the format of the combined data

Might revert: remove test that doesn't apply, now that there's 1 DB

Make api.database-test pass, though expected could be wrong

* Update unit tests for combined dataset

* Bump Bigquery version from v3_ to v4_

* Bump v3_test-data to v4_test-data

* Remove wrapping with mt/dataset

Alphabetize fk-mappings

* Remove needless whitespace edits

* Fix failed e2e_test by removing reference to sample-dataset

* Fix tests for Mongo, Oracle, Snowflake, and Presto

* Fix unit tests again for Mongo, Presto, and Snowflake

* Will revert: run driver tests on my fork

* Will revert: run driver tests on my draft fork

* Revert "Will revert: run driver tests on my draft fork"

This reverts commit 078c8af1.

* Revert "Will revert: run driver tests on my fork"

This reverts commit e3e2922f.

* Make the postgres driver test pass again by reverting a change

* Apply Case Nelson's patch to fix Athena test

https://github.com/metabase/metabase/pull/36064#issuecomment-1824837705
Props @snoe

* Remove (mt/dataset sample-dataset) from new tests

* Maybe fix Athena driver tests

Revert needless deletions of (mt/dataset test-data
Maybe those deletions caused the
failing Athena driver tests.
But those deletions are out of scope
for this PR either way.

* Remove sample-dataset reference from a test in the master merge

* In card_test.clj, replace sample-dataset with test-data

* Merge in master, resolve conflict in pivot-from-model-test

* Merge in master, resolve conflict in pivot-from-model-test

* Must revert: allow databse creation

To see if it will fix:
https://github.com/metabase/metabase/actions/runs/7120808552/job/19388845720?pr=36064#step:3:441


Athena database creation is disabled: not creating database v2_test_data. Tests will likely fail.

* Revert "Must revert: allow databse creation"

This reverts commit d4c8f129.

* Add back in (mt/dataset where I deleted it

But replace sample-dataset with test-data.
This might be wrong, or maybe it's not needed in
so many places.
But it could show if this is the problem.

* Fix the failed sync test

---------

Co-authored-by: Case Nelson <case@metabase.com>

* Bump dependencies based on vulnerabilities

* More deps bumped

* Bump more deps

* Rollback H2 dependency bump

* Add comments and make guava match elsewhere.

Those are:
- 8eb45851
- 930bbc5a
- 16988f50

Reason is that I'm not yet able to explain UTC night CI failures. That is WIP.
More context can be found on slack in https://metaboat.slack.com/archives/C5XHN8GLW/p1702332392764369?thread_ts=1701772468.810829&cid=C5XHN8GLW

* Revert "Temporarily skip server-side-relative-datetime-honeysql-form (#36567)"

This reverts commit 769b5eb4.
This was not flaking.

* Skip test that flakes

* Use date instead of timestamp

* Update logging and add code for local testing

* Rename datetime to date

* WIP: Use server side generated timestamps for :relative-datetime

* Use correct timestamp in :relative-datetime and add tests

* Update tests

* Remove combinations of tzs test

I've added those to commit in case we
need to refer to it in future. Tests like that take ~500 seconds,
hence good for one off testing.

* Update docstrings and comments

* Use string formatted qp.timezone/now as a base

* Address review remarks

* Remove redundant data from "last queries" query

* Update tests

- Add comment that points on discussion on flake potential of a test.
- Correct the order of expected and actual in another test.
- Add formatting to rows and select only necessary for testing in a test.

* Fix query remarks on Snowflake

* Move docstrings out of defmethod

* Add test to Snowflake query remarks

* Improve test on Snowflake query remark

* Remove unnecessary comment

This replaces the existing setting max-results-bare-rows with two settings:

- `max-unaggregated-query-row-limit`, and
- `max-aggregated-query-row-limit`

* Use mongo sessions in aggregation pipelines

Using sessions, cancel signal from streaming response can be handled
correctly - query is killed also on database side.

* Update tests

* Let the middleware handle the exception

While coding the other test, I've found out that if exception is handled
in the `reducible-results`, code clogs for 3 minutes,
which is `.maxTime` for aggregation. I don't know the exact reason yet,
but for time being I'm leaving the exception handling to middleware.

* Add testing string

* Encode aggregation results as `BasicDBObject`

Use this type instead of BSON's Document because code transforming
DBObject to clojure structures is already in place.

* Update exceptions handling and tests

Exception handling now more resembles code in other drivers. Tests were updated
to use mbql query instead of raw native to avoid differences between various
mongodb versions. `$dateTrunc` was not available in version 4.

* Increase cancelation interval in tests

* Address remarks and update test to handle cold start

By cold start I mean running it before dataset is initialized.

* Remove unnecessary hint