[FLINK-40270][connector-base][runtime] Make source threads job-attributable via MDC propagation and thread names

[Savonitar]

What is the purpose of the change

On a session / multi-tenant TaskManager, source data-plane and coordinator threads carry no job identity, so their logs and thread dumps cannot be attributed to a job (source operator names collide across jobs). Building on the JobInfo API from FLINK-39776, this PR closes three gaps:

1. Split fetcher threads (SplitFetcherManager): the fetcher pool did not inherit the task thread's SLF4J MDC, so every connector SplitReader logged with an empty flink-job-id, and the "Source Data Fetcher for ..." thread name carried no job identity.
2. Source coordinator worker executor (SourceCoordinatorContext): callAsync work (e.g. periodic file-split scans) still logged without flink-job-id.
3. Coordinator thread name (SourceCoordinatorProvider): SourceCoordinator-<operatorName> is identical for two jobs using the same source operator name. The thread-name suffix (truncated job name + full hex job id) deliberately matches the flink-job-id MDC value, so thread dumps correlate with log output.

Brief change log

• MdcUtils: new jobThreadNameSuffix(JobInfo) helper (job name capped at 32 chars, the length of the hex JobID that follows it).
• SplitFetcherManager / SingleThreadFetcherManager: new constructor overload with a trailing @Nullable JobInfo, when provided, the thread factory seeds the job id into each pool thread's MDC once and appends the job suffix to the thread name. All existing constructors delegate with null and keep their exact previous behavior.
• SourceCoordinatorContext: worker executor wrapped with MdcUtils.scopeToJob.
• SourceCoordinatorProvider: job suffix appended to the coordinator thread name (the derived -worker pool inherits it).

Verifying this change

This change added tests:

• MdcUtilsTest: suffix format, exact truncation boundary (at cap / cap + 1), empty and null job names.
• SplitFetcherManagerTest: on a real fetcher thread, the MDC carries the job id and the thread name carries the exact suffix; the no-JobInfo constructors preserve the historical thread name and empty MDC.
• SourceCoordinatorContextTest: callAsync callables run with the job id in the MDC.
• SourceCoordinatorProviderTest: the lazily created coordinator thread's name contains the job name and id.

Does this pull request potentially affect one of the following parts:

• Dependencies (does it add or upgrade a dependency): (no)
• The public API, i.e., is any changed class annotated with @Public(Evolving): (yes / no)
• The serializers: (no)
• The runtime per-record code paths (performance sensitive): (no)
• Anything that affects deployment or recovery: JobManager (and its components), Checkpointing, Kubernetes/Yarn, ZooKeeper: (no)
• The S3 file system connector: (no)

Documentation

• Does this pull request introduce a new feature? (no)
• If yes, how is the feature documented? (not applicable)

---

Was generative AI tooling used to co-author this PR?

• Yes (please specify the tool below)

Generated-by: Claude Opus 4.8 (1M context) noreply@anthropic.com

[flinkbot]

CI report:

• 53d54c1 Azure: FAILURE

Bot commands

The @flinkbot bot supports the following commands:

• @flinkbot run azure re-run the last Azure build