…ames (#69571)

### What problem does this PR solve?

Issue Number: None

Related PR: #69567

Problem Summary:

**In short.** A query of a Paimon table with a BINARY / VARBINARY
partition column now fails with an error naming
`'partition.legacy-name'` when it would read a non-NULL binary partition
whose files Paimon cannot locate, instead of silently returning only the
rows of the other partitions. This is the read-side counterpart of
#69567, which rejects writes to such tables.

**Background.** Paimon looks for the files of a partition under the
directory its partition values name, computed when the split is planned;
a writer puts the files under the name it computes when it writes. With
`partition.legacy-name = true`, the default, the name of a value is its
`toString()`, which for a binary value is the Java array object
(`[B@1b6d3586`) rather than its bytes, so every resolution differs. With
`partition.legacy-name = false` it is the text of the bytes (`p=AB` for
`X'4142'`). The option can be changed on an existing table, which
changes how existing partitions are looked up but does not move their
files. The BE skips a file of an external table that no longer exists
(`ignore_not_found_file_in_external_table`, default true), which is
meant for files removed between planning and reading.

**The problem, and what it cost.** Measured on master with Paimon 2.1.0,
on a `file://` Paimon catalog of a local FE + BE, with tables created
and written through the Paimon API:

| Table | Paimon API read | Doris before this PR |
|---|---|---|
| legacy names (default), rows in `X'4142'`, `X'EF'`, NULL | fails:
`FileNotFoundException` (`p=%5BB@...`) | `SELECT *` returns only the
NULL row; `COUNT(*)`, answered from metadata, returns 3 |
| legacy names when `X'4142'` was written, then `'partition.legacy-name'
= 'false'` and rows in `X'4344'`, NULL | fails: looks for `p=AB`, the
file is under `p=%5BB@...` | returns 2 of 3 rows, the `X'4142'` row is
missing |
| new names when `X'4142'` and NULL were written, then
`'partition.legacy-name' = 'true'` | fails | returns 1 of 2 rows |
| legacy names, rows only in the NULL partition | reads | reads
correctly |

So the query succeeds with a partial result and nothing tells the user.
Following the obvious fix, setting `'partition.legacy-name' = 'false'`,
does not make the old partitions readable either; it only moves the loss
to the files written before the change.

**How this PR fixes it.** `PaimonScanPlanProvider.planScanInternal`
checks every data split that will read files (after the splits whose
`COUNT(*)` is answered from metadata) whose binary partition value is
not NULL:

- if the split is looked up under legacy names (the options of its
table, or of its branch for a fallback read), planning fails;
- otherwise, if one of its data files was written under a schema whose
options use legacy names (the file's `schemaId`, looked up once per
schema and branch, inside the catalog authentication) and is also
missing at its planned path (`bucketPath/fileName`, the path the native
reader is given), planning fails and names that file. The schema alone
does not prove how a file was named: a writer's dynamic options
(`spark.paimon.*`, Flink hints, `Table.copy`) keep the schema ID, so a
file written with a dynamic `'partition.legacy-name' = 'false'` on a
table that keeps the default refers to a schema with legacy names while
it sits under the bytes of its value, and it is read once the table uses
those names;
- and, on a table with `'index-file-in-data-file-dir' = 'true'`, every
deletion vector the split carries must exist, whether or not its data
file has an external path, or planning fails and names the deletion
vector file and its data file. Such a table keeps its deletion vectors
with its data files: one written while no external data path is
configured records only its file name and is looked up under the
directory of its partition, which a legacy name never finds, while its
data file keeps its external path, and the BE skips the whole data file
when it cannot open the deletion vector. The option is immutable, so
every writer used the reading table's value. Deletion vectors under the
table's `index/` directory do not depend on partition names and are not
checked.

A NULL partition is named after `partition.default-name` under both
namings, and a data file with an external path is read from the path its
metadata records, so neither is rejected; the deletion vectors of a file
with an external path are still checked. The system tables read through
JNI (`$audit_log`, `$row_tracking`) report the options of the main
branch, while a fallback split is planned and read under its own branch,
so the check resolves the branch that produced each split from the
pinned source of the wrapper, as it does for data tables. `$binlog`
exposes its partition columns as arrays and is not checked; Paimon's own
reader fails on a file it cannot find. A
`scan.file-creation-time-millis` read of a fallback table plans the main
branch through its `SnapshotReader`, and its plain splits are judged
under the main branch. The error names the table, the partition and the
option. The existence checks run inside the catalog authentication, once
per path and scan: a table that keeps its index files under `index/` and
whose files were written under its current naming makes no extra
filesystem calls.

**Not covered.** A file written with a dynamic `'partition.legacy-name'
= 'true'` (or by a Paimon writer too old to know the option) while its
schema says `'false'` sits under a legacy name but is looked up under
its bytes, and the BE still skips it, as on master and branch-4.2.
Catching it would take an existence call for every file of every
non-NULL binary partition on every scan.

**Results.** On the same local cluster, after this PR:

| Query | Doris after this PR |
|---|---|
| `SELECT *` of the legacy table (also with `force_jni_scanner = true`)
| fails: `Cannot read Paimon table d.api_legacy: the table uses legacy
partition names ('partition.legacy-name' = 'true'), under which Paimon
names partition p = 0xEF after a Java array object rather than its
bytes, so the files of the partition are never found. Paimon cannot read
the partition either; ...` |
| `SELECT COUNT(*)` of the legacy table | 3, answered from metadata as
before |
| `SELECT * ... WHERE p IS NULL` of the legacy table | the NULL row;
Paimon prunes the other partitions |
| `SELECT *` of the table switched to new names | fails: `... data file
data-b3abc825-...-0.parquet of partition p = 0x4142 was written while
the table used legacy partition names ...`, the file the Paimon API read
reports as not found |
| `SELECT *` of the table switched back to legacy names | fails: `...
the table uses legacy partition names ...` |
| `SELECT *` of the legacy table with only NULL partitions, and of
tables with new names | all rows, the same as the Paimon API read |

`PaimonScanPlanProviderTest` adds eight tests: a scan under legacy names
fails while the NULL partition and `COUNT(*)` still plan; a file written
under legacy names fails after the option changes to false, and a file
written under the new names fails after it changes back to true; a file
at an external path still plans and points at an existing file; a file
at an external path whose deletion vector was written after the external
paths were removed (persisted the way
`PaimonSparkWriter.persistDeletionVectors` does it for a DELETE) fails
and names the deletion vector, while a deletion vector written with the
external paths in place still plans and points at an existing file; a
file written through `table.copy({"partition.legacy-name": "false"})` on
a table that keeps the default fails as a legacy lookup, then plans once
the option is altered to `false`; a fallback table whose main branch
holds only a NULL partition and whose fallback branch holds a non-NULL
binary partition plans the data table and `$audit_log` when the fallback
branch names partitions by bytes, and the planned `$audit_log` splits
read both rows back through Paimon, while both fail at planning with the
legacy-name error when only the main branch names them by bytes; and a
`scan.file-creation-time-millis` read of a fallback table with a
non-NULL binary partition plans the main branch's file.
`nativeBinaryPartitionsKeepAllPathValues`, added by #68786 for the
rendering of binary partition values, now creates its table with
`'partition.legacy-name' = 'false'`: under legacy names the files it
planned did not exist. The new tests fail when the lookup check, the
check of the files' schemas, the exemption of external paths or of NULL
values is removed, when the check moves before the `COUNT(*)` splits,
when the deletion vectors are not checked, when every deletion vector
fails without its existence being checked, when a file whose schema uses
legacy names fails without its existence being checked, when a system
table read through JNI is checked under the wrapper's options, when
every split is judged under the main branch, or when a split that does
not come from the fallback scan is cast to a fallback split (the
file-creation-time read then failed with a `ClassCastException`). The
853 tests of fe-connector-paimon run without failures (one is skipped,
as before).

No regression test is added: Doris cannot create a binary column, so the
tables would have to come from the Spark container of the Paimon docker
environment, which was not run locally.

### What problem does this PR solve?

Issue Number: None

Related PR: #69567

Problem Summary:

**In short.** A CASE WHEN whose result type is VARBINARY and that has
two or more WHEN branches failed in BE with `argument_type VarBinary not
supported`. BE now selects VARBINARY values the way it selects strings.

**Background.** VARBINARY values reach queries through external tables
(Iceberg, Paimon and Hive binary columns map to VARBINARY) and through
`CAST(... AS VARBINARY)`. BE evaluates CASE WHEN in `VCaseExpr`: it
computes, for every row, the index of the branch that the row takes, and
then `VCaseExpr::_execute_update_result` builds the result column,
dispatching on the result's primitive type to a typed copy loop. Nereids
rewrites a CASE with a single WHEN and an ELSE into `if()`, whose
generic path copies values through `IColumn::insert_from` and accepts
any column type.

**The problem, and what it cost.** The dispatch in
`_execute_update_result` had no entry for `TYPE_VARBINARY`, so it fell
through to `NOT_IMPLEMENTED_ERROR`. Every query with such a CASE failed,
whatever the constant-folding mode (the CASE is evaluated by BE, not
folded), for example

```sql
SELECT CASE WHEN number % 3 = 0 THEN CAST(concat('a', number) AS VARBINARY)
            WHEN number % 3 = 1 THEN CAST('y' AS VARBINARY)
            ELSE X'FF' END
FROM numbers("number" = "6");
-- ERROR 1105 (HY000): errCode = 2, detailMessage = (127.0.0.1)[NOT_IMPLEMENTED_ERROR][E3]
-- argument_type Nullable(VarBinary) not supported
```

Only a CASE with one WHEN and an ELSE worked, because it is evaluated as
`if()`. branch-4.2 has the same gap.

**How this PR fixes it.** `TYPE_VARBINARY` now maps to
`ColumnVarbinary`, and `ColumnVarbinary` takes the per-row copy
(`update_result_normal`) that CASE already uses for strings, both for a
nullable result (including CASE without ELSE, whose unmatched rows are
NULL) and for a non-nullable one. FE needs no change.

**Results.**

| CASE WHEN with a VARBINARY result | Before | After |
|---|---|---|
| Two or more WHEN branches, with ELSE | fails: `argument_type VarBinary
not supported` | returns the selected bytes |
| Two or more WHEN branches, without ELSE | fails: `argument_type
Nullable(VarBinary) not supported` | returns the selected bytes, NULL
for unmatched rows |
| One WHEN with ELSE (rewritten to `if()`) | works | works (unchanged) |

- BE unit tests: `VCaseVarbinaryTest` adds two cases through
`_execute_update_result`: a non-nullable result with ELSE (a column
branch, a constant branch, NUL and non-UTF-8 bytes) and a nullable
result without ELSE (NULL from a branch and from unmatched rows). Both
fail without the change with the error above. `VCaseSelectionTest` still
passes (50 cases in total).
- Regression test:
`query_p0/sql_functions/binary_functions/test_varbinary_case_when` runs
CASE with and without ELSE over a table, over `numbers()` and on
constants, in the three constant-folding modes (FE folding, folding by
BE, no folding); the results match in all modes.