Enhancement/bridge task management

[Rajil1213]

Description

This PR:

• adds tracking for retry_counts associated with a particular duty and discards duties after a user-configurable number of retries have occurred
• crashes the bridge client if the connection to the strata-client fails so that it can be externally restarted by a manager (docker, k8s). This is for convenience so that we don't have to manually go and restart the container (as it just hangs in its current implementation). Furthermore, as all DB updates happen via transactions there shouldn't be a need to do any explicit cleanup.

Type of Change

• [ ] Bug fix (non-breaking change which fixes an issue)
• [x] New feature/Enhancement (non-breaking change which adds functionality or enhances an existing one)
• [ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)
• [ ] Documentation update
• [ ] Refactor

Checklist

• [x] I have performed a self-review of my code.
• [x] I have commented my code where necessary.
• [ ] I have updated the documentation if needed.
• [x] My changes do not introduce new warnings.
• [ ] I have added tests that prove my changes are effective or that my feature works.
• [x] New and existing tests pass with my changes.

Related Issues

Closes STR-505

[codecov[bot]]

Codecov Report

Attention: Patch coverage is 17.80822% with 180 lines in your changes missing coverage. Please review.

Please upload report for BASE (releases/0.1.0@13159fb). Learn more about missing BASE report.

Files with missing lines	Patch %	Lines
...n/bridge-client/src/modes/operator/task_manager.rs	0.00%	66 Missing :warning:
bin/strata-cli/src/seed/password.rs	0.00%	30 Missing :warning:
bin/strata-cli/src/seed.rs	0.00%	19 Missing :warning:
bin/strata-client/src/helpers.rs	0.00%	16 Missing :warning:
bin/datatool/src/main.rs	0.00%	15 Missing :warning:
bin/strata-cli/src/cmd/change_pwd.rs	0.00%	11 Missing :warning:
bin/strata-client/src/keyderiv.rs	0.00%	10 Missing :warning:
bin/bridge-client/src/modes/operator/bootstrap.rs	0.00%	9 Missing :warning:
crates/state/src/header.rs	0.00%	3 Missing :warning:
crates/state/src/block_validation.rs	0.00%	1 Missing :warning:

@@                Coverage Diff                @@
##             releases/0.1.0     #394   +/-   ##
=================================================
  Coverage                  ?   56.98%           
=================================================
  Files                     ?      256           
  Lines                     ?    27046           
  Branches                  ?        0           
=================================================
  Hits                      ?    15413           
  Misses                    ?    11633           
  Partials                  ?        0           

Files with missing lines	Coverage Δ
bin/bridge-client/src/args.rs	0.00% <ø> (ø)
bin/strata-cli/src/constants.rs	100.00% <100.00%> (ø)
bin/strata-client/src/main.rs	0.00% <ø> (ø)
crates/bridge-sig-manager/src/manager.rs	93.70% <ø> (ø)
crates/bridge-tx-builder/src/context.rs	86.36% <ø> (ø)
crates/bridge-tx-builder/src/deposit.rs	95.79% <100.00%> (ø)
crates/bridge-tx-builder/src/operations.rs	96.42% <ø> (ø)
crates/btcio/src/writer/builder.rs	98.03% <100.00%> (ø)
crates/crypto/src/lib.rs	92.68% <100.00%> (ø)
crates/primitives/src/bridge.rs	86.30% <100.00%> (ø)
... and 18 more

[Rajil1213]

can we have some elaboration as to why duty exec would fail and why retrying it is safe?

This is because of two reasons:

• As all writes to the databases are wrapped in DB transactions, any application crashes should not render the database entries corrupted afaik.
• Retrying a duty is basically resigning transactions (and also redoing all the ceremony around it). We only create one private nonce per unique transaction which means the public nonce derived from it will always be the same. The signature is also going to be the same because the public nonce and the private key for a bridge client is also going to be the same, and the position of the keys is determined by their OperatorIdx which is in the chainstate/params and guaranteed to be the same too. So the worst that can happen when we retry duties is that we send a transaction whose input UTXO has already been spent.

[Rajil1213]

Rebased this PR accidentally from main instead of releases/1.0 (old habits). Closing this PR and creating a new one instead.