Pipe: Retry history LoadTsFile while waiting for schema

[Caideyipi]

Problem

When a full pipe is auto-split, historical data TsFiles can be delivered by the history/data side before the schema metadata side finishes replaying the current schema. If the receiver has enable_auto_create_schema=false, LoadTsFile schema verification may see a missing device or measurement and fail the history TsFile with LOAD_FILE_ERROR.

That failure is too strong for Pipe: in inclusion=all, the missing schema can still arrive from the schema stream. Treating the file as a permanent load failure can drop the history TsFile and produce partial data loss on the receiver.

Behavior after this change

This patch does not bypass the receiver's enable_auto_create_schema=false setting and does not force Pipe-generated LoadTsFile to auto-create database or timeseries schema from the TsFile.

Instead, for Pipe-generated LoadTsFile only, the receiver now classifies the failure as temporary when all of these are true:

• schema verification is enabled;
• receiver auto schema creation is disabled;
• the failure chain indicates a missing device or measurement that cannot be auto-created.

In that case LoadTsFile returns LOAD_TEMPORARY_UNAVAILABLE_EXCEPTION. The Pipe statement status visitor maps it to PIPE_RECEIVER_TEMPORARY_UNAVAILABLE_EXCEPTION, so the sender keeps retrying instead of treating the history TsFile as a permanent failed file.

Other LoadTsFile failures, such as corrupted files, type conflicts, non-Pipe loads, and errors without the missing-schema signal, still follow the existing permanent failure handling.

Why this is better for Pipe

This preserves the semantic contract of inclusion=all: schema should be transferred by the metadata stream, even if it arrives after a historical data TsFile. The data side waits for that schema instead of creating receiver schema from historical TsFile metadata.

It also avoids resurrecting schema that was deleted before pipe creation. Historical TsFiles may still contain old metadata, while the schema snapshot represents the current source schema. Retrying until the schema side catches up is safer than overriding the receiver's auto-create setting and potentially recreating deleted timeseries.

For async active LoadTsFile, this also works with the existing active-load retry policy because ActiveLoadFailedMessageHandler already retries LOAD_TEMPORARY_UNAVAILABLE_EXCEPTION.

Tests

• Added unit coverage for Pipe LoadTsFile missing-schema temporary classification.
• Added unit coverage for mapping LOAD_TEMPORARY_UNAVAILABLE_EXCEPTION to Pipe receiver temporary unavailable status.
• Added an integration test for auto-split full Pipe history TsFile loading with receiver auto schema creation disabled.

Local checks run:

• mvn -Ddevelocity.off=true -pl iotdb-core/datanode spotless:check
• mvn spotless:apply -pl integration-test -P with-integration-tests
• git diff --check

Targeted unit test command was attempted, but this local workspace currently fails during unrelated datanode main compilation before tests run, with missing generated/parser symbols and unrelated Pipe constants.

[jt2594838]

Will the message one day be involved in i18n?
If so, the contains() call may become dangerous.

[Caideyipi]

Updated in 2b62bd9: LoadTsFile schema-wait detection now uses a dedicated LoadAnalyzeMissingSchemaException and LOAD_TEMPORARY_UNAVAILABLE_EXCEPTION, and the pipe status visitor no longer classifies by message text such as contains(memory).

[jt2594838]

i18n

[Caideyipi]

Updated in 2b62bd9: moved the missing device/measurement schema messages and the pipe schema-wait message into DataNodeQueryMessages for en/zh i18n.