refactor: check for contract deployment before creating pn
supersedes https://github.com/RequestNetwork/requestNetwork/pull/945 and https://github.com/RequestNetwork/requestNetwork/pull/943
Context
The advanced-logic layer is a stateless singleton that contains an instance of all payment networks (PN). When created (see its class), it has no knowledge of what chain(s) it will be used on. It only needs an instance of the currency manager. It has no other dependency.
Issue / Solution
It is a pain to manually update PN whenever we want them to support a new chain, especially when it could be done automatically via our smart contract artifacts. Without adding new dependencies on the advanced-logic object, this can be done from the payment-detection layer. PN should have zero knowledge of what chain(s) they support. Routing from the chain/version to the payment network should be done during the instantiation of the payment detector.
From this point:
-
isValidAddressin PNs now only accepts an address (no morenetworkparameter), this means:- PN supporting EVM chains then support EVM addresses (that was already the case)
- PN can now only support one type of address, so all Near-related PN had to be split in two: one for Near mainnet and one for Near testnet, the same way we already had one for BTC and one for BTC-testnet
- PN don't accept a
supportedNetworksparameter anymore. Classes that extendnative-tokenandany-to-nativestill have asupportedNetworksarray as they need some kind of deeper level of routing. However, those are supper specific and not supposed to change that often once they are set. - everything Near related has been moved to its own directory in
advanced-logic, like we did inpayment-detection - the advanced-logic package typing has been updated (removed
anywhenever possible)
Ideally, those changes should not impact the behavior of the library when used for payment detection.