feat: tss funds migration

[kingpinXD]

Description

Please include a summary of the changes and the related issue. Please also include relevant motivation and context. List any dependencies that are required for this change.

Closes:

Type of change

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• This change requires a documentation update

How Has This Been Tested?

Please describe the tests that you ran to verify your changes. Include instructions and any relevant details so others can reproduce.

• Tested CCTX in localnet
• Tested in development environment
• Go unit tests
• Go integration tests
• Tested via GitHub Actions

Checklist:

• I have added unit tests that prove my fix feature works

[ws4charlie]

I think for real Tss migration (TSS had 3 hundreds of UTXOs in Athens3), if we pays only outTxBytesMin of fee, it may take many blocks (10min per block) for the outTx (many many inputs) to be accepted in a block.

For TSS migration, the thing is to make sure the old tss address has enough funds >= 80_000 sats (4000 * gasPrice (e.g., 20)) to move its own funds away.

Also, I believe the hard coded estimateFee = 4000 can be improved in future too, but that only helps in cases when TSS has only $10 (for example) of BTC in reserve and we want to move $5 to new TSS and paying another $5 as gas fee.

To conclude, we can just remove the estimateFee adjustment.

[kingpinXD]

Not sure I understand completely, you mean to remove the estimate fee component completely?

[ws4charlie]

I think comment out line 74 and leave the calculation estimateFee := float64(gasPrice.Uint64()) * outTxBytesMax / 1e8 as is would be enough.

[github-actions]

!!!WARNING!!!
nosec detected in the following files: zetaclient/bitcoin_client.go

Be very careful about using #nosec in code. It can be a quick way to suppress security warnings and move forward with development, it should be employed with caution. Suppressing warnings with #nosec can hide potentially serious vulnerabilities. Only use #nosec when you're absolutely certain that the security issue is either a false positive or has been mitigated in another way.

Only suppress a single rule (or a specific set of rules) within a section of code, while continuing to scan for other problems. To do this, you can list the rule(s) to be suppressed within the #nosec annotation, e.g: /* #nosec G401 */ or //#nosec G201 G202 G203
Broad #nosec annotations should be avoided, as they can hide other vulnerabilities. The CI will block you from merging this PR until you remove #nosec annotations that do not target specific rules.

Pay extra attention to the way #nosec is being used in the files listed above.

[ws4charlie]

looks good to me

[lumtis]

@kingpinXD looks like there is a Lint issue blocking the merge