[improvement](be) Schedule load bitmap and flush work by global priority

[sollhui]

What problem does this PR solve?

Problem Summary:

Foreground bitmap computation and memtable flush use separate execution pools, so a bitmap backlog does not directly reduce the rate at which flush workers produce new segments. Share those workers and dispatch ready foreground tasks by global priority within each resource domain. Duplicate-key loads only have flush work, so assign their flushes P1.

Design

Shared execution resources

Foreground bitmap computation and memtable flush share the existing flush workers. The default pool and workload-group pools remain separate. Reuse ThreadPool worker management, queue capacity, metrics, and adaptive sizing. Ordinary non-load submissions retain their existing scheduling policy.

Remove the independent LoadCalcDeleteBitmapThreadPool, TabletCalDeleteBitmapThreadPool, and high-priority memtable flush pool. Foreground callers of TabletCalcDeleteBitmapThreadPool move to the shared workers; background compaction and schema-change work retains the general bitmap executor. TaskWP_CALC_DBM_TASK remains the separate request orchestration/waiting pool, and SyncDeleteBitmapThreadPool remains separate.

Global task priority

Each resource domain has four global FIFO queues. Every ready load task enters its priority queue directly. There is no outer load queue, transaction round robin, or transaction ID in the scheduling API. Workers select the highest nonempty priority queue:

Priority	Work
P0 / HIGHEST	Commit/publish bitmap computation, derived segment computation, and tablet finalization
P1 / HIGH	Write-end bitmap reconciliation and DUP-key memtable flush
P2 / MID	Write-time segment bitmap computation, including its existing file-close step
P3 / LOW	Other memtable flush, including MoW and aggregate-key tables

Flush priority is selected from the rowset writer's tablet schema. A group rowset writer's data and row-binlog flushes both follow the main table's priority; a MoW table's row-binlog schema does not promote its flush to P1.

Priority applies across all queued load tasks in a domain. Tasks of the same priority are dispatched in FIFO order, including tasks belonging to different loads or tokens. Running tasks are not preempted, and completion order may differ with multiple workers. Load tokens retain completion/cancellation boundaries but impose no per-load concurrency limit; one token can use all available workers.

Submission, selection, and cancellation use ThreadPool::_lock. Cancelling a token scans the four queues and removes only that token's tasks, preserving FIFO order for the others. Removed callbacks and their captured resources are destroyed outside the pool mutex.

Backpressure after flush

A normal MoW writer creates its bitmap token before flush execution. When a flush produces a segment, it enqueues P2 bitmap work and returns without waiting. Ready P2 work takes precedence over queued P3 flushes across the resource domain. Slow bitmap work occupies shared workers and slows subsequent flushes. Unflushed memtables retain memory, so existing memory limits and write-side waits propagate pressure upstream. Already-running flushes continue; this design adds no bitmap-byte admission budget.

DUP flushes share P1 with write-end bitmap reconciliation, so they take precedence over P2/P3 work. This does not guarantee per-load fairness: sustained P0/P1 traffic can delay lower-priority work.

Dependencies, context, and completion

Cloud commit tablet tasks hold tablet locks while calculating segment bitmaps. A bitmap token created inside a load worker executes its children inline to avoid waiting for children queued to the same pool. This retains serial segment calculation within a cloud tablet; different tablets can run concurrently. Local publish runs outside the shared pool and can submit P0 segment tasks and wait there. Transient publish writers also classify their bitmap work as P0.

Inline children inherit the current task context and tablet memory tracker. Asynchronously submitted bitmap callbacks attach their captured ResourceContext, and cloud tablet work switches the memory tracker within that attached context.

Flush-worker cleanup can release the last rowset-writer reference. Cancelling its P2 token removes queued work, then joins already-running independent bitmap leaves. A worker cannot join its own token. Submitted/completed counters prevent discarded bitmap callbacks from being reported as successful completion during pool shutdown. The selected workload group stays alive until its underlying pool token is released. Submission failures are retained in the bitmap token so wait() returns the original error instead of a generic cancellation. Cloud request completion drains all submitted tokens before returning its recorded tablet/submission error; a wait failure is used when no earlier error was recorded.

Workload-group routing

The cloud transaction cache records the write-stage workload group. Commit selects the tablet's first available cached owner, including subtransaction entries. Cloud DELETE agent tasks have no attached resource context; cache registration records no workload group for them and uses the default domain without calling resource_ctx() on an unattached thread. Missing entries or a dropped workload group use the default domain. One tablet commit is not split across multiple workload groups. Transaction IDs remain business identifiers but no longer affect task scheduling. No persistent metadata or wire-format change is introduced.

Release note

Foreground bitmap work shares memtable flush workers and receives global task priority per resource domain. DUP flushes run at P1; MoW and other flushes run at P3. The former calc_delete_bitmap_for_load_max_thread, calc_tablet_delete_bitmap_task_max_thread, and high_priority_flush_thread_num_per_store settings remain parseable but no longer size independent pools; is_high_priority no longer selects a separate pool. Flush sizing/adaptive controls govern shared foreground work, while calc_delete_bitmap_max_thread continues to size background bitmap work.

Check List (For Author)

• Test: Added/updated unit tests for global priority, FIFO across tokens, cancellation, unrestricted token parallelism, nested context inheritance, cleanup, and schema-based DUP/MoW/AGG flush priority.
  • clang-format 16, build hygiene, and git diff --check passed for the latest changes.
  • Attempted bash run-be-ut.sh --run --filter='LoadTaskQueueTest.*:LoadThreadPoolTest.*:MemTableFlushExecutorTest.DuplicateFlushPrecedesWriteTimeBitmap' -j 4. Dependency acquisition failed while fetching apache-orc because github.com could not be resolved. C++ compilation and unit test execution have not completed.
  • Throughput and latency have not been measured.
  • Added error-path coverage for unattached Cloud DELETE cache registration, workload-group capture/detach, queue-full and stopped-pool submission errors, and cloud error precedence. The latest targeted command (LoadThreadPoolTest.*:CloudTxnDeleteBitmapCacheTest.*:CloudEngineCalcDeleteBitmapTaskTest.*) stopped during the JDK environment check; directly invoking the configured JDK reports Failed setting boot class path. These tests have not compiled or run. clang-format 16, build hygiene, and whitespace checks passed.
• Behavior changed: Yes, foreground pool allocation and scheduling change as described above.
• Does this need documentation: Yes, design and tradeoffs are documented here.

Check List (For Reviewer who merge this PR)

• Confirm release notes and retired pool configuration behavior
• Build BE and run the added unit tests
• Validate concurrent MoW/DUP, partial updates, row binlog, retries, cancellation, and workload-group deletion
• Measure priority starvation and cloud tablet segment parallelism tradeoffs

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