Fix remaining data race in BurningManAccountingStore

Add missing synchronisation to the 'toProtoMessage' method, by first
copying the internal list of blocks inside a read-lock, prior to
serialisation (still outside the lock, to maximise concurrency). Since
we only make a shallow copy, this should be fast and take no more than a
MB or so of extra memory.

This prevents a race seen to cause a ConcurrentModificationException
during store persistence, that sometimes occurred when the application
resumed from a long suspension.

core/src/main/java/bisq/core/dao/burningman/accounting/storage/BurningManAccountingStore.java

@@ -17,7 +17,6 @@
 
 package bisq.core.dao.burningman.accounting.storage;
 
-
 import bisq.core.dao.burningman.accounting.blockchain.AccountingBlock;
 import bisq.core.dao.burningman.accounting.exceptions.BlockHashNotConnectingException;
 import bisq.core.dao.burningman.accounting.exceptions.BlockHeightNotConnectingException;
@@ -160,9 +159,17 @@ private void purgeLast10Blocks() {
     }
 
     public Message toProtoMessage() {
+        List<AccountingBlock> blocksCopy;
+        Lock readLock = readWriteLock.readLock();
+        readLock.lock();
+        try {
+            blocksCopy = new ArrayList<>(blocks);
+        } finally {
+            readLock.unlock();
+        }
         return protobuf.PersistableEnvelope.newBuilder()
                 .setBurningManAccountingStore(protobuf.BurningManAccountingStore.newBuilder()
-                        .addAllBlocks(blocks.stream()
+                        .addAllBlocks(blocksCopy.stream()
                                 .map(AccountingBlock::toProtoMessage)
                                 .collect(Collectors.toList())))
                 .build();