Centralization of the coin wallet services

[kponichtera]

Currently there is one, centralized service for handling Bitcoin wallet through the bitcoinj library: the WalletService class in the common library module of the superapp. However, there are also dedicated Ethereum wallet wrappers, which are used in the liquidity pool app. Because they are stored in the app's Gradle module, they cannot be reused without extracting them into a common one. What's more, although these wrappers provide convenient facade for the geth and web3j Ethereum libraries, they do not provide the same functionality as the Bitcoin's WalletService (creating the wallet in the application data directory when necessary and managing connectivity with network's peers). Instead, they expect the wallet to be created separately and passed to them, which is infeasible to be done in multiple places around the app.

Since not all apps in the superapp are using Bitcoin and Ethereum, it would be good to create separate libraries common-bitcoin and common-ethereum and include them as dependencies in the other Gradle modules that require Bitcoin and Ethereum. This would help with the modularity and further maintenance of the superapp, since there would be natural separation of concerns, enforced by the Gradle project structure (eg. classes from the common library module will not be able to access the Bitcoin and Ethereum classes).

However, although multi signature wallet wrappers for Bitcoin were possible to be easily extracted to common-bitcoin, the WalletService itself cannot be moved to the separate library right now due to other classes in the common library module being dependent on it. What's more, there are cyclic dependencies between the WalletService and other classes in the common module, like the TransactionRepository.

Team Atomic Swap analyzed the situation with the wallets in the superapp and managed to extract the Ethereum wallet wrappers from the liquidity pool app into dedicated library common-ethereum. Also, we managed to create a dedicated EthereumWalletService which behaves similarly to the Bitcoin's one. Since it already resides in its dedicated library module, the aforementioned problems with cyclic dependencies between the classes of different concerns are prevented by design.

@devos50 FYI