[FLINK-39984][runtime][webUI] Support LITE/FULL thread dump modes

[xingsuo-zbz]

What is the purpose of the change

Fixes FLINK-39984. Clicking "Thread Dump" on a JobManager or TaskManager in the Web UI can cause the targeted process to miss heartbeats and be marked dead by the JobManager, taking down otherwise healthy running jobs.

The dominant cost is not the RPC dispatch but the underlying JVM safepoint: JvmUtils#createThreadDump unconditionally calls ThreadMXBean.dumpAllThreads(true, true), which requires walking every thread's locked-monitor and j.u.c. synchronizer state inside a single JVM-wide safepoint. On JVMs with many threads (Netty + RocksDB + async I/O + user threads — 10k+ in production is not uncommon) this pauses the entire JVM (including the heartbeat dispatcher) for seconds to tens of seconds. If the pause exceeds heartbeat.timeout (default 50 s), the JM triggers an unnecessary TaskManager failover on what was intended as a purely diagnostic action.

This PR makes the dump granularity configurable so operators can pick a mode whose safepoint pause is bounded well
below heartbeat.timeout. A companion PR under the same JIRA additionally offloads the dump construction to
ioExecutor so the RPC mailbox no longer stalls behind the dump; the two fixes are complementary but independent.

Brief change log

• Introduce ThreadDumpMode {LITE, FULL} and thread it through RestfulGateway / TaskExecutorGateway /
  ResourceManagerGateway / TaskExecutorGatewayDecoratorBase / NonLeaderRetrievalRestfulGateway.
  • LITE → dumpAllThreads(false, false) — stack traces only, negligible JVM pause.
  • FULL → dumpAllThreads(true, true) — current behavior, retains locked-monitor / synchronizer info for deadlock analysis.
• Expose the mode as an optional REST query parameter ?mode=lite|full on both /jobmanager/thread-dump and /taskmanagers/{id}/thread-dump via a new ThreadDumpModeQueryParameter and two new MessageParameters classes; unknown values become HTTP 400.
• Add config option cluster.thread-dump.default-mode (default FULL) that controls the fallback when no query parameter is supplied. Default is deliberately FULL to preserve the existing on-upgrade behavior; the description flags LITE as the recommended value for large clusters. A separate dev@ discussion will decide whether to flip the default in a future release.
• Web UI: add a Lite / Full toggle to both thread-dump pages
  (flink-runtime-web/web-dashboard/.../{job,task}-manager/thread-dump/). Selecting a mode does not auto-fetch; the user must press the refresh button (avoids surprising the operator when they merely click the toggle). The download link tracks the current selection so exported dumps match the on-screen content.

Verifying this change

This change added tests and can be verified as follows:
New unit tests

• ThreadDumpModeQueryParameterTest — 6 cases covering key name, optionality, case-insensitive parsing of LITE/FULL,
  unknown value → IllegalArgumentException, and lower-case serialization.
• TaskExecutorThreadDumpTest — spins up a real TaskExecutor and verifies that (a) requestThreadDump returns a
  non-empty dump for null, LITE, and FULL, and (b) when mode is omitted the request honors
  cluster.thread-dump.default-mode (the test overrides it to LITE and asserts the "Number of locked synchronizers"
  section is absent, which only appears in FULL).

Existing tests updated

• TestingResourceManagerGateway, TestingTaskExecutorGateway, TestingRestfulGateway — signature updates for the new
  ThreadDumpMode parameter.
• rest_api_v1.snapshot — new mode query parameter recorded for both endpoints; RuntimeRestAPIStabilityTest passes
  against the updated snapshot.

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): 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: yes (Before this change, requesting a thread dump on a busy TM could cause a spurious Heartbeat of TaskManager timed out. After this change the
  request no longer blocks the RPC mailbox and when the operator selects LITE, the
  safepoint pause is short enough not to trip heartbeat.timeout.)
• The S3 file system connector: no

Documentation

• Does this pull request introduce a new feature? yes — the new ThreadDumpMode REST parameter and cluster.thread-dump.default-mode config option.
• If yes, how is the feature documented? docs

---

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

• Yes (please specify the tool below)

Generated-by: Claude Code (Claude Opus 4.7)

[flinkbot]

CI report:

• 86388ac Azure: SUCCESS

Bot commands

The @flinkbot bot supports the following commands:

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

[spuru9]

A few minor comments before the review:

1. The commit message can a co-author reference contradiction the PR guidelines.
2. Can you fix the test issue. They appear to be genuine issues.

[xingsuo-zbz]

@flinkbot run azure

[xingsuo-zbz]

@spuru9 done,please continue to review

[Myasuka]

I think we should split this PR into two PRs, one is to use ioExecutor instead of main thread; one is to introduce new feature that we can have options to select when creating thread dumps.

[xingsuo-zbz]

I think we should split this PR into two PRs, one is to use ioExecutor instead of main thread; one is to introduce new feature that we can have options to select when creating thread dumps.

@Myasuka The ioExecutor offload lives in a companion PR#28778 under the same JIRA.