[refactor](catalog) fe-core: delete the unreachable metastore property cluster and the dead storage/AWS-credential surface

[morningman]

What problem does this PR solve?

Issue Number: #65185

Problem Summary:

Part of the catalog-SPI migration (#65185). Review round 21, targeting branch-catalog-spi.

This round is one self-contained work line: finish the architectural goal "fe-core holds no
property parsing" for org.apache.doris.datasource.property. Everything here is deletion of code
that is unreachable on this branch — nothing moves and nothing is migrated, because every successor
is already live connector-side. fe-core loses ~860 lines and gains none. The investigation, the
per-package verdicts, the rejected alternatives and the rolling handoff are included under
plan-doc/fecore-property-cleanup/.

The two packages under datasource/property/ were investigated together but got different
verdicts, and are deliberately not treated as one job:

package	verdict	reason
metastore/ (4 files, 333 lines) + the orphaned ConnectionProperties	deleted outright	unreachable at runtime; its successor has been live for some time — nothing needs to move
common/ (2 files, 237 lines)	stays in fe-core, only its provably dead half is cut	it serves internal storage (cold-storage StoragePolicy, cloud StorageVault), not external datasources; every relocation target is dependency- or classloader-illegal

1. The metastore property cluster is deleted, not migrated

datasource/property/metastore/ (4 files) plus the ConnectionProperties base it orphans. The
successor is already running: fe-connector-metastore-api MetaStoreProperties,
fe-connector-metastore-spi MetaStoreProviders.bind and Connector.deriveStorageProperties.

The cluster was unreachable. Its registry held only TRINO_CONNECTOR, whose factory returns a bare
MetastoreProperties without ever calling initNormalizeAndCheckProps — so it parsed nothing, and
createInternal, getDerivedStorageProperties, getExecutionAuthenticator and the
StorageAuthenticatorBridge all had zero callers. CatalogProperty was the sole importer and
offered two doors: checkMetaStoreAndStorageProperties (no callers repo-wide) and
resolveDerivedStorageDefaults, whose metastore branch runs only when
pluginDerivedStorageDefaultsSupplier is null — and PluginDrivenExternalCatalog installs that
supplier unconditionally. Nothing here was Gson-persisted, so no image or replay compatibility is at
stake (note MetastoreProperties.Type is unrelated to the persisted InitCatalogLog.Type /
InitDatabaseLog.Type constants of the same name).

resolveDerivedStorageDefaults now throws when the supplier is unwired instead of deriving
nothing. That preserves today's behavior, where the metastore parse threw on this path. Deriving an
empty map would silently drop the iceberg warehouse → fs.defaultFS bridge and, because the setter
deliberately does not reset caches, would cache the under-derived StorageBindings for good.
CatalogPropertyPluginStorageDerivationTest gains a case pinning that, and its stale mutation
comments are retargeted at mutations that still exist.

2. The callerless AWS provider-instance arm is dropped

StorageAdapter.getAwsCredentialsProvider() and its two helpers build a live AWS SDK v2 credentials
object for FE-side SDK clients; AwsCredentialsProviderFactory.createV2, createDefaultV2 and the
single-arg getV2ClassName existed only to serve that arm. Both consumers — the catalog connectivity
testers and IcebergAwsClientCredentialsProperties — were removed earlier in this migration along
with the whole datasource/connectivity package, so nothing calls them here anymore.

This one is a deliberate trade, not merely dead code. It is still live on apache/doris master,
where both consumers exist; it reads as dead only on this branch. Removing it means future upstream
edits to that region will surface as modify/delete conflicts on rebase, to be resolved by keeping the
deletion. The investigation first flipped its own recommendation to do not delete for exactly that
reason (see the [doc](catalog) record that the dead AWS provider arm is live upstream commit); the
owner then accepted the trade, and only after that was the deletion carried out.

Deliberately kept, because they are not part of that arm: getAwsCredentialsProviderMode() and
the s3CredentialsMode field, and AwsCredentialsProviderFactory.getV2ClassName(mode, boolean) with
its two env probes. Those emit the provider class-name string that reaches BE via
AWS_CREDENTIALS_PROVIDER_TYPE and the hadoop fs.s3a.aws.credentials.provider map, and
AzureGuessRoutingParityTest pins the mode accessor. Folding them into the look-alike
fe-filesystem-s3-base twin was considered and rejected: the two implementations differ in two
live behaviors (the hadoop string gains a ProfileCredentialsProvider; the accepted mode strings
widen), and no test in the repo pins the emitted string — so the swap would have shipped a regression
green. Three connector comments naming the deleted methods are reworded; the iceberg twin is now the
only implementation of the provider-instance mapping.

3. The dead storage doors on the catalog base are removed

Five callerless members of ExternalCatalog — getHadoopProperties, getConfiguration, buildConf,
buildHadoopConfiguration, ifNotSetFallbackToSimpleAuth — together with the cachedConf /
confLock fields they cached through, and three of CatalogProperty — getHadoopProperties,
getBackendStorageProperties, getOrderedStorageAdapters — with their two lazily populated fields.
getConfiguration was already marked deprecated "until connector SPI extraction is complete", which
it now is.

The point is not the 135 lines. initStorageAdapters is now reachable only through
getStorageAdaptersMap and getEffectiveRawStorageProperties, both called from
PluginDrivenExternalCatalog, so "fe-core storage has a single entrance" holds by construction
rather than by audit — which is also what backs the fail-loud branch in item 1.

4. Two test-infrastructure notes (no code)

plan-doc/fe-core-ut-runtime-problem.md records, with measurements rather than guesswork, why a full
fe-core run takes 3h+: reuseForks=false (deliberate, to avoid singleton conflicts) means a fresh
JVM per class at ~5.5s startup over 1225 classes, forkCount comes from fe_ut_parallel which
defaults to 1 unless FE_UT_PARALLEL is set, and nereids accounts for 72% of test execution time. It
also records what the FE UT pipeline actually runs — TeamCity Doris_Doris_FeUt invokes the repo's
own run-fe-ut.sh --coverage, passes -Dmaven.test.failure.ignore=true, and forces the exit code
back to 0 when a run has more than 6000 tests with at most 10 failures and 10 errors, so a green FeUt
build is not the same as zero failures. Both notes are directions only, filed for a separate branch —
raising FE_UT_PARALLEL is untested and risks fork contention over ports, BDB directories and temp
paths.

Release note

None

Check List (For Author)

• Test
  • Regression test
  • Unit Test
  • Manual test (add detailed scripts or steps below)
  • No need to test or manual test. Explain why:
    • This is a refactor/code format and no logic has been changed.
    • Previous test can cover this change.
    • No code files have been changed.
    • Other reason

Local verification, stated at the coverage it actually has:

• repo-wide grep for every deleted symbol: clean.

• full reactor clean test-compile including test sources (no -Dmaven.test.skip), after each
  of the four deletions: BUILD SUCCESS. Deletion changes cannot be trusted to incremental compilation,
  so fe-core/target/{classes,test-classes} was removed before each run.

• fe-core checkstyle:check: 0 violations.

• targeted suites: 95 fe-core tests including the Gson replay suites; 110 fe-connector-api tests
  with connector-metadata-methods.txt unchanged; 52 storage-adapter and catalog-property tests
  (1 pre-existing @Disabled in LocationPathTest).

• the full fe-core suite was not run to completion. It was still going at 3h29m after 1232 test
  classes and was stopped by the owner rather than finished, so the claim is "no failures among the
  1232 classes executed", not "the suite passes". Its one failure,
  ForwardToMasterTest.testAddBeDropBe (ClassCastException: JSONObject → JSONArray), reproduces
  identically on a clean HEAD with these changes stashed, so it is pre-existing.

• no e2e was run (no cluster available here); this PR adds no regression case. All four deletions
  remove unreachable code, and the storage-binding path they sit next to (iceberg hadoop
  warehouse → fs.defaultFS) is covered by unit tests only. CI is relied on for the rest.

• no BE file is touched by this PR, so BE was not rebuilt.

• Behavior changed:

  • No.

Every deleted member is callerless on this branch. The one semantic change —
resolveDerivedStorageDefaults throwing when pluginDerivedStorageDefaultsSupplier is unwired — is
not reachable in production wiring, since PluginDrivenExternalCatalog installs that supplier
unconditionally, and it replaces a path that already threw. The one accepted forward cost is stated in
item 2: modify/delete rebase conflicts against upstream master in the StorageAdapter region.

• Does this need documentation?
  • No.

[hello-stephen]

Thank you for your contribution to Apache Doris.
Don't know what should be done next? See How to process your PR.

Please clearly describe your PR:

1. What problem was fixed (it's best to include specific error reporting information). How it was fixed.
2. Which behaviors were modified. What was the previous behavior, what is it now, why was it modified, and what possible impacts might there be.
3. What features were added. Why was this function added?
4. Which code was refactored and why was this part of the code refactored?
5. Which functions were optimized and what is the difference before and after the optimization?