…tion

A duplicated key-value argument such as
s3('http://...', format = 'CSV', format = 'TSV') is user-controlled input,
but parseKeyValueArguments threw LOGICAL_ERROR on the duplicate-key emplace.
LOGICAL_ERROR aborts debug builds and is treated as a critical failure by
stress and fuzzer checks, so a user typo must not produce it. On this branch
the helper still lives in Storages/ObjectStorage/S3/Configuration.cpp
(pre-dates the shared ObjectStorage/Utils.cpp refactor).

Backport of 4939661 (already applied to the
26.4 private backport), needed here too since the new secret-masking tests
from #109768 exercise this exact duplicate-key path.

Closes: #104267

findS3FunctionSecretArguments only special-cased the named-collection
form for non-cluster functions (isNamedCollectionName(0)), so
s3Cluster('cluster', named_collection, ...) fell through to the
positional url/secret classification meant for the literal-url form,
leaving the named collection's secret_access_key (and session_token,
Google ADC secrets) unmasked. Ported master's findS3NamedCollectionSecretArguments
helper and its use in findS3FunctionSecretArguments, findS3TableEngineSecretArguments
and findS3DatabaseSecretArguments, matching the fully merged state of #109768.

This is what test_mask_sensitive_info/test.py::test_table_functions_object_storage_cluster
caught on this backport (amd_asan and amd_tsan integration runs).

#112333

BACKUP TABLE ... TO S3('https://user:pass@localhost:11111/x?...', 'ak', 'sak')
relied on the one-character bucket name being rejected by S3 URI
validation before any network access, matching master's comment for
this case. On this branch BACKUP's S3 destination locator parses the
url without going through S3::URI: the userinfo confuses its ad-hoc
host:port parsing into a bogus endpoint ("user:0"), and the resulting
request is misclassified as retryable, so BackupsWorker retries it
(s3_retry_attempts = 1000) instead of failing fast. The client hung
for the full 600s test timeout, and the background backup task then
kept the server from shutting down cleanly.

The masking behavior itself already works (the query is logged with
the userinfo and signature correctly hidden before the hang); only
the "fails before any network access" assumption doesn't hold here.

#112333

findTableEngineSecretArguments's S3-family dispatch (S3, COSN, OSS,
DeltaLake, Hudi, Iceberg, IcebergS3, S3Queue) was missing GCS and
DeltaLakeS3, even though both exist as table engines on this branch
(StorageObjectStorageDefinitions.h) and are included in master's
merged state of #109768. Engines that fell through this dispatch got
no masking at all: SHOW CREATE TABLE and the query log showed their
secret_access_key in plaintext, as caught by
04510_s3_explicit_url_named_secret_mask's ENGINE = GCS(...) case.

#112333

The `Backup` database engine (`ENGINE = Backup(database_name, S3(...))`)
reconstructs its nested `S3(...)` destination for logging, since that
destination isn't itself recognized as an S3 engine when the formatter
recurses into an argument rather than `function`. This whole function,
its dispatch entry, the `quote_replacement` field it needs on `Result`
(to emit the reconstructed call as raw SQL text instead of a quoted
string), and the matching ASTFunction.cpp formatting change all exist
in #109768's own commits (42bda2e, ced7e82) and in master's
merged state, but were dropped entirely in this cherry-pick: on this
branch, `CREATE DATABASE ... ENGINE = Backup('db', S3('url','ak','sk'))`
showed the secret access key in plaintext in SHOW CREATE and the query
log, and nothing in the trimmed 25.8 test file caught it.

Ported the function, wiring, and the corresponding SQL/reference test
cases from 04510_s3_explicit_url_named_secret_mask (skipping the two
cases with a userinfo-bearing localhost:11111 URL, which hit the same
BACKUP-destination-parsing hang already worked around for the plain
BACKUP TO S3 case), plus the integration test case in
test_mask_sensitive_info::test_create_database.

#112333