[hotfix] Change writerState flush from async to sync while rolling log to avoid conflicts with the writerState flush during logTablet close

[swuferhong]

Purpose

This pr is aims to change writerState flush from async to sync while rolling log to avoid conflicts with the writerState flush during logTablet close.

In the LogTablet#roll() method, the current implementation writes the writerState while holding the lock, but the file flush operation is performed outside the lock. However, this could potentially conflict with the writerState write operation in the LogTablet#close() method. Considering that the writerState flush operation itself is not very resource-intensive and the roll() method isn't called frequently, we consider change it to a sync flush approach.

Brief change log

Tests

API and Format

Documentation

[wuchong]

It seems Kafka introduced the async on purpose to address a performance problem when flushing the writer state takes too long. What exception/problem when using async?

https://issues.apache.org/jira/browse/KAFKA-15046
apache/kafka@d71d063

[swuferhong]

It seems Kafka introduced the async on purpose to address a performance problem when flushing the writer state takes too long. What exception/problem when using async?

https://issues.apache.org/jira/browse/KAFKA-15046 apache/kafka@d71d063

When testing the Fluss cluster update, the Fluss tabletServer shutdown also needs to call writerStateManager.takeSnapshot(). If this conflicts with the takeSnapshot in the roll() method, it may happen that the shutdown process acquires the lock before the roll() has flushed the snapshot and proceeds to write the snapshot, which will cause errors. Therefore, a better approach than async flushing should be used here to address the issue of blocking writes.