…s needs to be fixed

…olumn_v2

…ing stuff, and sadly includes the other patch as well..

…e the threshold at which late materialization is triggered

…constructor is called

…ack of it with an atomic

This is already in the auto-install list, should be in the auto-load
list as well

…ack of it with an atomic (duckdb#15798)

…orage version when serializing a database (duckdb#15794)

Follow-up from duckdb#15702
Supersedes/builds on top of duckdb#14981

This PR change the `storage_compatibility_version` from being a setting
set on every session to be written in the database file.

Previously we would set this setting at run-time, and it would be shared
across all database instances:

```sql
ATTACH 'file1.db';
-- write something, to be serialized targeting version v0.10.0
SET storage_compatibility_version = 'v1.0.0';
ATTACH 'file2.db';
-- write something, to be serialized targeting v1.0.0
```

This has a number of issues:

* The storage compatibility version is shared across all attached
databases
* When restarting the system, the `storage_compatibility_version` would
revert back towards the default setting (currently `v0.10.0`)
* When reading a database, we did not know which storage compatibility
version was used, which could lead to hard to understand errors when
reading databases with an older version

### STORAGE_VERSION parameter

This PR reworks this so that the storage version is instead specified on
`ATTACH`. When none is specified:

* The version set in the `storage_compatibility_version` is used when
creating a new database
* The version stored within the database is used when loading an
existing database

As a result, we can target the storage version towards the desired
supported version when creating a new database. When opening an existing
database, we will keep on writing targeting the same DuckDB version
(i.e. we never automatically "upgrade" the file to a newer DuckDB
version). The user can *manually* upgrade a file by opening an older
file while targeting a later storage version.

For example:

```sql
-- use default `storage_compatibility_version`
ATTACH 'new_file.db';
-- explicitly target versions >= v1.2.0
ATTACH 'new_file.db' (STORAGE_VERSION 'v1.2.0');

-- use the storage version stored within the file
ATTACH 'existing_file.db';
-- use storage version v1.2.0 - if the file uses an older storage version, this upgrades the file
ATTACH 'existing_file.db' (STORAGE_VERSION 'v1.2.0');
```

Note that we cannot *downgrade* a file. If we try to open a file that
targets e.g. version v1.2.0 with an explicit storage version of v1.0.0,
we get an error:

```sql
ATTACH 'database_file.db' (STORAGE_VERSION 'v1.2.0');
DETACH database_file;

ATTACH 'database_file.db' (STORAGE_VERSION 'v1.0.0');
-- Error opening "database_file.db": cannot initialize database with storage version 2 - which is lower than what the database itself uses (4). The storage version of an existing database cannot be lowered.
```

### Opening with DuckDB < v1.1.3

When opening a file that targets `v1.2.0` in an older DuckDB version, we
now get a storage incompatibility error:

```sql
duckdb database_file.db
```

```
Error: unable to open database "database_file.db": IO Error: Trying to read a database file with version number 65, but we can only read version 64.
The database file was created with an newer version of DuckDB.

The storage of DuckDB is not yet stable; newer versions of DuckDB cannot read old database files and vice versa.
The storage will be stabilized when version 1.0 releases.

For now, we recommend that you load the database file in a supported version of DuckDB, and use the EXPORT DATABASE command followed by IMPORT DATABASE on the current version of DuckDB.

See the storage page for more information: https://duckdb.org/internals/storage
```

The description in the error is not entirely correct - but the error is
a lot more descriptive than the previous error that would be thrown in
this scenario (which was `INTERNAL Error: Unsupported compression
function type`).

The error message has also been improved in
duckdb#15702 already.

These tests were inadvertendly disabled because the name of the require flag changed sometime back.

These tests
```
test/sql/json/test_json_copy_tpch.test_slow -- 1
test/sql/aggregate/group/test_group_by_parallel.test_slow -- 2
test/sql/parallelism/intraquery/depth_first_evaluation.test_slow -- 3
```
 Were giving memory/storage issues in CI.

For (1.), I've reduced the TPC-H scale factor to 0.1 instead of 1. We're
still testing what we want to test, so this shouldn't be an issue (TPC-H
files are really large when exported to JSON).

For (2.), the setting `PRAGMA verify_external;` was triggering a lot of
partitioning and spilling to test the external grouped aggregation
behavior. It was spilling more than necessary because the HT size
calculation was off a bit, especially when this setting was enabled.

For (3.), a slight increase to the memory limit in the test was enough
to make it work again. We're still testing the behavior we want to.

…lying on default

This PR is a follow-up from duckdb#14175 that changed the return value of
`map_extract` and `element_at` to return a single value from maps by key
instead of a list with the value.

This is a good change, but unfortunately It breaks backwards/forwards
compatibility for serialized query plans. This PR fixes it by reverting
the change to `map_extract` but instead add a new `map_extract_value`
with the new behavior. It also changes the syntax sugar (e.g. `[]`) to
use this new function instead, so the end user still "mostly" sees the
new behavior, while the system internally still keeps the same behavior
for the actual function.

* SelectionVector(start, count) should respect the count when
initializing
* `ColumnFetchState` needs to be transaction-local, not part of the
global state

* Big ROW_GROUP_SIZE require explict STORAGE_VERSION
* ALTERNATIVE_VERIFY=1 implies default to be `latest`, so test do not
make much sense

These tests were inadvertently disabled because the name of the require
flag changed sometime back.

Note: The same should be checked on all extension tests (I think a test
from the fts extension has the same issue).