[Pipe] Fix processor worker starvation on pipe stop

[Caideyipi]

Description

• Add an epoch-based execution guard so a processor invocation that observes STOP yields even if the pipe is immediately started again.
• Check the guard around TsFile-close waits, parser admission, Tablet boundaries, and OOM backoff; yielding is neutral control flow and preserves the current event and parsing progress.
• Make parser admission non-blocking for processor subtasks so a task that is not admitted immediately yields its worker while keeping its fair-queue request.
• Cancel pending parser requests on STOP and release active parser reservations from the processor worker before yielding.
• Add a deterministic shared-worker test covering a stopped Pipe, a parser-waiting Pipe, and a running Pipe in the same worker round.
• Watch each processor worker for a continuously running event. Log the worker stack after 10 minutes and at most once every 30 minutes for the same event; cap the event description at 1 KiB and the stack at 64 frames.

Tests

• mvn -o -nsu test -pl iotdb-core/datanode -Dtest=PipeProcessorSubtaskWorkerTest,PipeProcessorSubtaskExecutionGuardTest,PipeTsFileInsertionEventAdmissionTest,PipeMemoryManagerTest,PipeProcessorSubtaskExecutorTest
• mvn -o -nsu test -pl iotdb-core/datanode -Dtest=TsFileInsertionEventParserTest
• mvn -o test -pl iotdb-core/datanode -Dtest=PipeProcessorSubtaskWorkerTest,PipeProcessorSubtaskExecutionGuardTest -DfailIfNoTests=false
• mvn -o compile -pl iotdb-core/datanode -P with-zh-locale

[jt2594838]

No need to call getRootCause multiple times.

[Caideyipi]

Addressed in 29513e2: the exception root cause is now computed once and reused for both control-flow checks, avoiding repeated traversal.

[jt2594838]

Creating a static exception instance may miss the actual stack traces.
Is it expected?

[Caideyipi]

Yes, the static instances are intentional control-flow sentinels. They disable stack-trace creation because these exceptions are expected pause/yield signals rather than failures; the Reason enum identifies the requested action. A per-throw stack would add allocation cost without diagnostic value.

[jt2594838]

Is it possible to register this thread with the guard and let it interrupt registered threads when the epoch changes?

Frequent sleep-and-wake may reduce performance.

[Caideyipi]

The guard currently has no registered-thread facility; its 100 ms polling interval bounds stop latency while keeping the guard usable across the existing worker and parser call paths. Registering and interrupting sleeping threads would require a broader guard lifecycle change, so I am leaving that as a separate optimization.