Fix core dumps triggered by rocksdb compacting when shutdown bk

[AnonHxy]

Descriptions of the changes in this PR:

Fix #4705

Motivation

Fix #4705

Changes

1.Setting the compacting flag of entryLocationIndex as true when shutdown LedgerStorage to stopping the subsequent compact.
2. When LedgerStorage shutdown we will wait unit the compact end.

[zymap]

Shouldn't it be done in the close method in the EntryLocationIndex?

[AnonHxy]

make sense @zymap

[StevenLuMT]

This waiting could result in the system being stuck here indefinitely, or it could take an exceptionally long time to get stuck at this step.

Should we add a maximum waiting time, or do something else, such as modifying RocksDB operations?

[AnonHxy]

I dont think so. Closing a DB which in compaction status may triger core dumps or other unexpected error. If Closing the DB cost toot long time, I think we'd better find out why or kill -9 if we need.

The handling approach here is similar to the procedure below：

bookkeeper/bookkeeper-server/src/main/java/org/apache/bookkeeper/bookie/GarbageCollectorThread.java

Lines 770 to 772 in 3a5cf9d

	while (!compacting.compareAndSet(false, true)) {
	// Wait till the thread stops compacting
	Thread.sleep(100);

[StevenLuMT]

I have a question:

Is the isCompacting syntax the root cause of this problem?
Or is it simply a matter of rewriting the method more efficiently, thus ruling out issues with the isCompacting setting?

[AnonHxy]

Yes. It's the root cause. We should cancel the compacting if we have closed the DB, or we should delay closing the DB if we have already been in compaction status. So here We need an atomic variable to serve as a flag for the DB status. @StevenLuMT