Rate limit the job submission request

[hellolittlej]

What

Adds an opt-in, per route based bucket rate limit.For jobsRoute, add the rate limit in front of the three v1 job-creation endpoints:

• POST /api/v1/jobs
• POST /api/v1/jobClusters/{cluster}/jobs
• POST /api/v1/jobs/actions/quickSubmit

The rate

Configuration

Property	Default	Notes
mantis.master.api.v1.submitJob.throttle.enabled	false	Off by default; no limiter is constructed when off
mantis.master.api.v1.submitJob.permitsPerSecond	1000	Re-readable at runtime, no deploy needed

• Guava RateLimiter, non-blocking tryAcquire(); token-bucket with the usual ~1s of burst accumulation, so a 1000/s limit admits up to a ~1000-request burst after an idle period.
• Shed → HTTP 429, checked in BaseRoute.withThrottle:141 before the entity is unmarshalled — a storm costs a permit check, not a parse plus an actor ask.

Off by default because the right ceiling depends on cluster size and traffic —
operators opt in once they've measured their own submit rate. The rate is backed by a
LongDynamicProperty, so it re-reads on the dynamic-property refresh interval
(mantis.config.dynamic.refreshSecs, default 30s).

Metrics

MasterApiMetrics/throttledRequestCount gains a source tag (submitJob,
resourceCluster), so an operator can tell which limit is shedding. Previously the
route-level throttle and the resource-cluster gateway's RequestThrottledException
both incremented the same untagged counter.

Checklist

• ./gradlew build compiles code correctly
• Added new tests where applicable
• ./gradlew test passes all tests
• Extended README or added javadocs where applicable

[github-actions]

Test Results

167 files  + 3  167 suites  +3   10m 43s ⏱️ +25s
814 tests +17  802 ✅ +16  11 💤 ±0  1 ❌ +1 
815 runs  +18  803 ✅ +17  11 💤 ±0  1 ❌ +1 

For more details on these failures, see this check.

Results for commit 8d0199a. ± Comparison against base commit 25ff35c.

♻️ This comment has been updated with latest results.