[fix](routineload) Persist the current load definition

[0AyanamiRei]

What problem does this PR solve?

Issue Number: N/A

Related PR: #64878

Problem Summary:

This is the persistence and recovery prerequisite for future Routine Load ALTER work. It does not add target-table ALTER syntax or behavior.

Routine Load historically persisted the original CREATE statement in origStmt and reparsed it whenever an image was loaded. That statement is immutable, while ALTER ROUTINE LOAD changes the effective load clauses kept in RoutineLoadJob. After an ALTER followed by checkpoint/restart, reparsing the stale CREATE statement could therefore restore the original definition instead of the definition currently used to create tasks.

There are two independent persistence paths that must retain the same effective state:

• Image/checkpoint: persist the canonical runtime fields used by Routine Load tasks directly, including partitions, column mappings, preceding/where/delete filters, separators, sequence column, merge type, execution memory limit, and memtable_on_sink_node.
• ALTER journal: persist a nullable RoutineLoadDesc delta in AlterRoutineLoadJobOperationLog, apply properties and the load-clause delta under the job write lock on the leader, and apply them in the same order during follower replay.

The final design deliberately does not introduce a LoadDefinition wrapper or duplicate job/data-source property snapshots:

• Existing RoutineLoadJob fields remain the effective state and receive stable Gson keys.
• jobProperties remains authoritative for properties whose runtime caches are rebuilt after deserialization.
• New-format images restore direct state without creating a SQL context, accessing the catalog, or validating CREATE SQL.
• origStmt remains persisted for downgrade readability and for one-time migration of legacy images.
• An image without the newly persisted merge type is treated as legacy. The new FE reparses origStmt once, restores the load clauses and exec_mem_limit, and the next checkpoint naturally writes the direct-state format.
• Legacy memtable_on_sink_node cannot be reconstructed and retains its historical post-restart value of false.

The ALTER log stores only the changed RoutineLoadDesc clauses. Nullable fields preserve clauses not modified by that ALTER. Old logs do not contain this field and therefore leave the current definition unchanged during replay.

CSV ALTER properties are validated only on the leader before mutation. Replay trusts persisted journal values so that validation added by a newer FE cannot prevent replay of a journal written by an older FE. The cached enclose, escape, and empty_field_as_null values are kept in sync with jobProperties.

Because Routine Load converts legacy expressions back to SQL before building each Nereids task, the persisted expression graph must retain every field that affects SQL generation. This PR adds stable serialization for the relevant MatchPredicate, SlotRef, and TimeV2Literal fields and verifies SQL-equivalent Gson round trips.

Compatibility boundary:

• Old image -> new FE: supported through one-time origStmt migration. ALTER load clauses that were never recorded by the old image or old journal are not recoverable; the original CREATE semantics are restored.
• New image/log -> old FE: unknown JSON fields are structurally ignorable and origStmt is still available, but semantic downgrade is not guaranteed. An old FE may restore the original CREATE clauses and ignore new ALTER deltas.
• Avoid ALTERing Routine Load load clauses until every FE has been upgraded. During a mixed-version rolling upgrade, an old follower can ignore the new journal delta, while a new follower cannot reconstruct a delta omitted by an old leader.
• A checkpoint written by the new FE can therefore lose post-upgrade ALTER semantics if the cluster is rolled back to an older FE.

Out of scope:

• Target-table ALTER.
• Failed-ALTER atomicity refactoring.
• Pause/cancel reason persistence, automatic-recovery backoff, state-transition timestamps, and other unrelated Routine Load lifecycle issues.

Tests added:

• Direct Kafka/Kinesis image round trips with complete load clauses, non-default task properties, durable data-source state, and invalid origStmt to prove new images do not fall back to SQL parsing.
• Empty load-definition image recovery without origStmt parsing.
• Fixed image and ALTER-log fixtures generated by the real serializer at merge base a8928245, including provenance and explicit assertions for unrecoverable legacy state.
• ALTER journal serialization/replay for all load-clause categories, CSV cache synchronization, legacy logs without RoutineLoadDesc, and leader/replay checkpoint parity.
• Semantic expression round trips for analyzer selection, quoted slot labels/subpaths, and TIMEV2 literal values.
• A three-FE Docker case covering leader ALTER, follower journal replay before checkpoint, leader failover, a subsequent ALTER on the new leader, checkpoint creation, and FE restart recovery.

Validation status for the final head:

• git diff --check: passed.
• FE unit tests and the Docker regression case were added but were not executed after the final changes.

Release note

Routine Load jobs now preserve the effective load clauses after ALTER across follower replay, leader failover, checkpoint, and FE restart.

During a rolling upgrade, do not ALTER Routine Load load clauses until all FEs are running the new version. Rolling back after a new-version checkpoint can restore the original CREATE clauses instead of post-upgrade ALTER semantics.

Check List (For Author)

• Test

  • Regression test
    • Added a three-FE Routine Load journal replay, leader failover, checkpoint, and restart case.
    • Not executed after the final changes.
  • Unit Test
    • Added image, journal, legacy fixture, derived-state, CSV, and expression semantic coverage.
    • Not executed after the final changes.
  • Manual test
  • No need to test or manual test

• Behavior changed:

  • No.
  • Yes. New images and ALTER journals retain the current effective Routine Load definition; legacy images migrate once from origStmt.

• Does this need documentation?

  • No.
  • Yes. Rolling-upgrade and rollback limitations must be documented.

Check List (For Reviewer who merge this PR)

• Confirm the release note
• Confirm test cases
• Confirm document
• Add branch pick label

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