We have written all files each time at each new block which accumulated to about
1 GB of data, this led to stability issues and very high disk IO for the explorer nodes.
Now we write only the data of the new block. We also remove the deletion of all
files at startup.
The dao state is still written in a monolithic file so that cannot be optimized
but we added a new directly where we add each block named by block height.
Looking up the latest written file tells us our last persisted block.
So all that data is equivalent to the monolithic daoState data which should
be removed once the webapp devs have implemented the change to use the blocks directory.
This would fail once we update trade protocol version when we release segwit. So this fixes that as it only checks if the version is not the old version (1) where refund agents have not been part of the system.
Also checks for legacy arbitrator that it only can be used for version 1 cases. Not tested and not assumed that this code will be executed as old arbitrators would use the old app in case they need to still work on a old case.
We only do it for 2 weeks after planned release time as then it can be assumed that enough nodes have updated that the normal publishing will distribute the object sufficiently.
Add shutdown method to TradeStatisticsConverter and call it via TradeStatisticsManager. Now as we have a reference to TradeStatisticsConverter in we don't need the hack anymore in applyInjector.
Set log level for com.neemre.btcdcli4j.core.client.ClientConfigurator to error as there is an expected warn log because of the outdated version.
1. We do not want that initial data request/response use old trades statistics for excluded key hashes.
Thats why we return an empty map in getMap.
2. We do not read resource file as we have removed that.
3. We do not persist as we convert the existing data and re-publish as new data, or at startup we convert the old data to the new one and then delete the file.
We let seller publish trade stats to avoid those issues with duplicated entries as trade date is different.
We could fix that to use the same trade date, but it seems to be not needed that both traders are publishing and the
risk if a trade stat does not get successfully published does not cause real problems.
There is guarantee anyway that the data is broadcast even if both do it.
In case we still want to do it from both sides we need to use the sellers trade date which is exchanged early in the trade
protocol but yet not further used beside for account age check.
