Flushing the FileStore might return before data is persisted

The implementation of FileStore#flush might return before all the expected data is persisted on disk.

The root cause of this behaviour is the implementation of TarRevisions#flush, which is too lenient when acquiring the lock for the journal file. If a background flush operation is in progress and a user calls FileStore#flush, that method will immediately return because the lock of the journal file is already owned by the background flush operation. The caller doesn't have the guarantee that everything committed before FileStore#flush is persisted to disk when the method returns.

A fix for this problem might be to create an additional implementation of flush. The current implementation, needed for the background flush thread, will not be exposed to the users of FileStore. The new implementation of TarRevisions#flush should have stricter semantics and always guarantee that the persisted head contains everything visible to the user of FileStore before the flush operation was started.