branch-4.1: [fix](paimon) Keep write cache coherent and extend coverage

[suxiaogang223]

What

• move Paimon write suites and golden outputs under external_table_p0/paimon/write
• extend write coverage for sequence groups, MERGE semantics, sequence/rowkind, deletion vectors, row tracking/data evolution, external paths, partition deletes, bucket modes, and JDBC catalog concurrency
• keep the Doris Paimon metacache as the owner of table instances used by writes
• invalidate the same table in Paimon's CachingCatalog before reloading it after a Doris cache miss
• add FE unit coverage for cache invalidation and table reload behavior
• validate stable Doris query results through checked-in .out files
• keep unsupported behavior disabled with targeted TODO markers

Why

Doris currently has its own Paimon table metacache on top of Paimon's CachingCatalog. Invalidating only the Doris cache could still make the loader receive a stale Table from the underlying Paimon cache. As a result, writes after external metadata changes could continue using outdated bucket, path, or table options.

This change keeps the existing Doris cache boundary, documents why both cache layers exist, and makes a Doris cache reload invalidate the corresponding Paimon table entry first.

Testing

• source ./custom_env.sh && ./build.sh --fe
• source ./custom_env.sh && ./run-fe-ut.sh --run org.apache.doris.datasource.paimon.PaimonExternalMetaCacheTest,org.apache.doris.datasource.paimon.PaimonExternalTableTest
  • 31 tests, 0 failures, 0 errors
• normal-mode regression execution for the added Paimon write suites and JDBC catalog concurrency coverage
• focused .out verification after the cache fix:
  • test_paimon_write_bucket_modes
  • test_paimon_write_sequence_group
  • test_paimon_write_deletion_vector
  • test_paimon_write_external_paths
• git diff --check

[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?

[suxiaogang223]

run buildall

[suxiaogang223]

run buildall