Fix SimpleBatcher apparent deadlock #2196

[ggivo]

Closes #2196

Problem:

• Flush Operation Conflict:
    - When one thread (T1) performs a flush, it may read and dispatch batched commands before resetting the flushing flag.
    - If another thread (T2) adds a command and forced flush at this moment. Command might be added to the queue but does not trigger a flush.
    - As a result, the command remains in the queue until the next flush request, causing a delay in dispatching.

• Flag Reset Between Iterations:
    - During a default flush operation, if multiple batches are processed, the flushing flag is reset between iterations.
    - This allows another thread to take over, potentially causing the initial thread to return BatchTasks.EMPTY instead of properly processed commands.

1. T1 -> batch(command, CommandBatching.flush()
2. T1 -> flushing.compareAndSet(false, true) == true
3. T1 -> flush()->doFlush()
4. T2 -> batch(command, CommandBatching.flush()
5. T2 -> flushing.compareAndSet(false, true) == false  #already flushing will skip doFlush  and command remain not dispatched
6. T1 -> batch() completes
7. T2 -> batch() completes

Fix:

If force flush is requested while flushing, perform additional flush iteration after ongoing completes

Make sure that:

• You have read the contribution guidelines.
• You have created a feature request first to discuss your contribution intent. Please reference the feature request ticket number in the pull request.
• You applied code formatting rules using the mvn formatter:format target. Don’t submit any formatting related changes.
• You submit test cases (unit or integration tests) that back your changes.

[tishun]

My head really hurts after reading this code, but I am not sure I can simplify it any more than you have.

Perhaps we need to do some bigger refactoring around the flushing logic, but this bug is not the time.