Make Edge query and load-event thread pools configurable

[JackieTien97]

Description

Normal table queries in the Edge process eventually start 20 coordinator workers, 10 coordinator scheduling workers, 4 fragment-notification workers and 5 ConfigNode load-event workers. The latter three pool sizes were hard-coded, and Edge did not override the existing coordinator read-pool setting.

Make these pool sizes configurable at startup and use smaller Edge defaults:

Configuration	General default	Edge default
coordinator_read_executor_size (existing)	20	2
coordinator_scheduled_executor_size	10	2
fragment_instance_notification_thread_count	4	2
cn_load_statistics_publisher_thread_count	5	1

Values must be positive. Changes require a restart; the existing general defaults are preserved. The normal configuration template documents all four settings. ConfigNode and SchemaRegion continue to use Ratis; DataRegion continues to use IoTConsensus. JVM memory budgets and flush/compaction pools are unchanged.

Validation

• Clean distribution build with QueryThreadPoolConfigTest and LoadStatisticsPublisherConfigTest: four tests passed, covering defaults, positive-size validation, startup loading and restart-only behavior.
• IoTDBEdgeBasicIT: package settings, tree/table reads and writes, 160 queries over four concurrent table connections, and runtime consensus-protocol assertions.
• Full-reactor English and Chinese test compilation.
• Before/after runs with the same JVM settings on Linux aarch64, a two-CPU quota and 4 GiB available memory: 100 devices × 100 DOUBLE fields, 1 Hz writes, two writers and four readers for 180 seconds. Each run wrote and verified 1,810,000 values with no failed requests or missed write rounds. SHOW VARIABLES confirmed Ratis for ConfigNode/SchemaRegion in both runs.
• Mid-load jstack thread entries changed from 147 to 115. The four pools changed from 20/10/4/5 to 2/2/2/1. NMT thread committed memory changed from 16,881 KiB to 13,249 KiB. Observed RSS peaks were about 341 and 338 MiB; this change reduces thread overhead and does not establish a total RSS cap.

Self-review

• Reviewed concurrent query execution and event delivery.
• Documented configuration defaults and restart requirements.
• Added configuration tests and concurrent Edge integration coverage.
• Tested real read/write workloads with Ratis metadata consensus.