This change introduces two new protocols: `ClosureSynchronizer` and
`CombineSynchronizer`. These two protocols define API that doesn't use
`async`. So the client can choose exactly which API it wants to use.
This change also introduces two new objects: `ClosureSDKSynchronizer`
and `CombineSDKSynchronizer`. These two implement the respective protocols
mentioned above. Both are structures. Neither of these two keeps any state.
Thanks to this each is very cheap to create. And usage of these two isn't
mutually exclusive. So devs can really choose the best SDK API for each
part of the client app.
[#831] Use async inside of the SDKSynchronizer
- In general lot of methods inside the `SDKSynchronizer` and
`CompactBlockProcessoer` which weren't async are now async. And other
changes are made because of this change.
- `CompactBlockProcessor` no longer uses Combine to communicate with
`SDKSynchronizer`. Reason for this is that Combine doesn't play great
with async. Closure passed to `sink` isn't async.
- Because of this and because of how our tests work (receiving signals
from CBP directly) `CompactBlockProcessor` must be able to handle more
event closures. Not just one. So it now has `eventClosures`
dictionary. It's little bit strange but it works fine.
- `SyncStatus` inside the `SDKSynchronizer` was previously protected by
lock. Now it's protected by simple actor wrapper.
- Changes in tests are minimal. Changes were mady only because
`CompactBlockProcessor` changes from Combine to closures.
[#831] Add tests for ClosureSDKSynchronizer
- Added tests are testing in general if the `ClosuresSDKSynchronizer` is correctly
calling `Synchronizer` and if the values are correctly returned.
- `ClosuresSDKSynchronizer` doesn't contain any logic but it is public
API and we should be sure that it works correctly.
[#831] Add tests for CombineSDKSynchronizer
[#831] Add changelog
Michal Fousek