GeezerVison

📜 Description

Use an atomic scheduling state for the logs and metrics batch processors. A producer now claims delayed flush scheduling with compare-and-set, while a completed flush releases that claim before checking whether more events arrived.

This removes the lock and Future lifecycle checks that allowed an event to be queued without a pending flush. Regression tests verify that both processors schedule another flush after the previous flush has run.

💡 Motivation and Context

An event added while a flush was transitioning from an empty queue to resetting its scheduling flag could remain queued indefinitely. The running flush did not observe it, and the producer saw scheduling as already claimed.

Fixes #5739

💚 How did you test it?

• ./gradlew spotlessApply apiDump
• ./gradlew :sentry:test --tests 'io.sentry.logger.LoggerBatchProcessorTest' --tests 'io.sentry.metrics.MetricsBatchProcessorTest'

📝 Checklist

• I added GH Issue ID & Linear ID
• I added tests to verify the changes.
• No new PII added or SDK only sends newly added PII if sendDefaultPII is enabled.
• I updated the docs if needed.
• I updated the wizard if needed.
• Review from the native team if needed.
• No breaking change or entry added to the changelog.
• No breaking change for hybrid SDKs or communicated to hybrid SDKs.
• Public API changes reviewed by another Mobile SDK team member or implemented according to the develop docs spec.

🔮 Next steps

None.