fix(warehouse): close MetricsData after processing to release Arrow buffers

[paultanay]

What's changed?

DataStorageDispatch.startPersistentDataStorage() polls MetricsData objects from the queue and passes them through the history, plugin, and realtime writers, but never called close() afterward. MetricsData implements AutoCloseable and wraps an ArrowTable backed by Arrow column vectors - without close(), those vectors and their buffers are retained until GC decides to collect them. Under production load with many monitors this compounds into the steady heap growth reported in #4136.

Wrapped the polled object in try-with-resources so MetricsData.close() is guaranteed on all exit paths: normal completion, writer exception, and thread interrupt. DataStorageDispatch is the terminal consumer, so closing here is safe.

Fixes: #4136

---

Checklist

• I have read the contribution guidelines
• Existing tests pass (hertzbeat-warehouse, hertzbeat-common-core)

[Aias00]

Review: close MetricsData after processing to release Arrow buffers

Clean, minimal, and correct resource-leak fix.

What's good

• commonDataQueue.pollMetricsDataToStorage() is now wrapped in try-with-resources, so MetricsData.close() (releasing the underlying Arrow column-vector buffers) is guaranteed on every exit path: normal completion, writer exception, and thread interrupt. This directly addresses the steady heap growth reported in #4136.
• DataStorageDispatch.startPersistentDataStorage() is the terminal consumer of these MetricsData objects, so closing them here is safe — no downstream reader needs the Arrow buffers afterward.
• The original control flow is preserved exactly: the inner try/finally still ensures realTimeDataWriter.saveData(...) runs even if calculateMonitorStatus/history/plugin steps throw. The null-guarded continue is still valid under try-with-resources (a null resource is simply not closed).
• MetricsData implements AutoCloseable, so the compiler-enforced contract holds.

Non-blocking note

• Standard try-with-resources behavior means if close() itself throws, it would suppress an earlier exception from the body. That is an acceptable, rare edge for this terminal-sink path.

No blocking issues. Approve.

[paultanay]

CI failures are in the setup-deps infrastructure step (fails before any compilation). Build and all 88 tests pass locally under the release profile (mvn clean package -Prelease). Looks like a runner issue.