Remove pkg/coordinator package

[lukasz-zimnoch]

Refs: #3614

Here we remove the pkg/coordinator by moving their contents to pkg/maintainer/wallet. This package seems to be no longer needed so this operation makes the package structure and dependency graph simpler. This refactoring was done in several steps:

Step 1: Make the nomenclature in pkg/maintainer/wallet more precise

The tBTC v2 system defines two types of sweeps: deposit sweeps and moved funds sweeps. In the first step, we narrowed the existing nomenclature used within the wallet maintainer to remove ambiguity and make it clear that the existing code refers to deposit sweeps.

Step 2: Move the deposit sweep code from pkg/coordinator to pkg/maintainer/wallet package

In the second step, we moved the deposit sweep code living so far in the pkg/coordinator. By the way, some
simplifications were made in order to make the public API cleaner and more readable. After this change, the pkg/maintainer/wallet package exposes the following public API:

• FindDeposits that allows to find deposits according to the given criteria
• FindDepositsToSweep that finds a batch of deposits that are most suitable to become part of a deposit sweep
• ProposeDepositsSweep which submits a deposit sweep proposal to the WalletCoordinator contract
• EstimateDepositsSweepFee that estimates the deposit sweep transaction fee
• DepositReference which is a set of data allowing to identify and refer to a deposit
• Deposit that holds some detailed data about a deposit
• ParseDepositsReferences that allows creating an array of DepositReference based on the provided input string
• ValidateDepositReferenceString that allows to validate whether the given string can be used to create a valid DepositReference instance

This step also involved moving unit tests stressing the deposit sweep code described above.

Step 3: Move the redemption code from pkg/coordinator to pkg/maintainer/wallet package

In this step, we moved the redemption code from pkg/coordinator to the pkg/maintainer/wallet package. This was similar to the previous step but much simpler. After this step, the public API of the pkg/maintainer/wallet package was extended with the following items:

• FindPendingRedemptions which allows to find pending redemption requests
• ProposeRedemption which submits a redemption proposal to the WalletCoordinator contract
• EstimateRedemptionFee that estimates the redemption transaction fee

This step also involved moving unit tests stressing the redemption code described above.

Step 4: Move the coordinator.Chain interface

In the fourth step, we moved the coordinator.Chain interface by merging it with the maintainer/wallet.Chain interface.
This change clarifies the chain expectations defined by the pkg/maintainer/wallet package. We also moved the remaining chain types living so far in the pkg/coordinator (coordinator. NewWalletRegisteredEvent and coordinator. NewWalletRegisteredEventFilter) to the pkg/tbtc package. This package should be the right place for them according to the recent discussion (see #3650 (comment)), at least until #3652 is done.

Step 5: Remove pkg/coordinator package

In the last step, we removed the pkg/coordinator package and made sure all references from the cmd package were correctly replaced.

[pdyraga]

I need a clarification of this part of the PR description:

We also moved the remaining chain types living so far in the pkg/coordinator (coordinator. NewWalletRegisteredEvent and coordinator. NewWalletRegisteredEventFilter) to the pkg/tbtc package. This package should be the right place for them according to the recent discussion (see #3650 (comment)), at least until #3652 is done.

This move makes sense if there are more than two chain interfaces using the type. In this particular case, only the pkg/maintainer/wallet uses it. Wouldn't it make more sense to keep this type defined inside the pkg/maintainer/wallet/chain.go?

[lukasz-zimnoch]

I think it will be much easier to declare all chain types in pkg/tbtc, regardless of what actually uses them.

First reason: we avoid scattering those types around packages and we have everything in one place - the core pkg/tbtc package. This makes reasoning easier.

Second reason: Imagine pkg/tbtc needs to use those types one day. If so, we will have an import cycle and we will have to move those types to pkg/tbtc anyway. Also, if we introduce a new package pkg/abc that will need those types, it will be cleaner if it depends on pkg/tbtc and not on pkg/maintainer/wallet.

[pdyraga]

That makes sense to me. Let's just make sure to be consistent about it cc @tomaszslabon @nkuba.

[pdyraga]

Not necessarily in this PR, but what do you think about going one step further and moving the coordinator CLI under ./keep-client maintainer coordinator umbrella?

When we deploy the automated version to mainnet, we should ideally have only one maintainer instance running that will take care of updating the light relay, submitting SPV proofs, and coordinating the wallet actions.

[lukasz-zimnoch]

Not necessarily in this PR, but what do you think about going one step further and moving the coordinator CLI under ./keep-client maintainer coordinator umbrella?

When we deploy the automated version to mainnet, we should ideally have only one maintainer instance running that will take care of updating the light relay, submitting SPV proofs, and coordinating the wallet actions.

Yeah, that makes sense!

[pdyraga]

Not necessarily in this PR, but what do you think about going one step further and moving the coordinator CLI under ./keep-client maintainer coordinator umbrella?
When we deploy the automated version to mainnet, we should ideally have only one maintainer instance running that will take care of updating the light relay, submitting SPV proofs, and coordinating the wallet actions.

Yeah, that makes sense!

Awsome, I added this to the tasklist in #3614 but let's not hold this PR. The diff is large enough already.