The recovery task broke out of its monitoring loop before getting the `UtxoScannerEvent::Completed` event. This PR just moves that break statement so that the final completed callback is made.

Also Ignore `test_store_and_forward_send_tx` due to it being flakey on CI and the functionality is covered by Cucumber tests.

## Description
The recovery task broke out of its monitoring loop before getting the `UtxoScannerEvent::Completed` event. This PR just moves that break statement so that the final completed callback is made.

## How Has This Been Tested?
Wallet clients will need to test this

## Checklist:
<!--- Go over all the following points, and put an `x` in all the boxes that apply. -->
* [x] I'm merging against the `development` branch.
* [x] I have squashed my commits into a single commit.

…cript

The `wallet_import_utxo` FFI function in LibWallet just used defaults for a number of the new UTXO fields when importing a faucet UTXO. The Faucet UTXO provided by the client is just the spending key and amount. The `metadata_signature` and `sender_offset_public_key` can both remain as default values as they are not used in spending an UTXO.  A Nop script is assumed and the spending key is used as the `script_private_key`. The final update is that the `input_data` it set as the public key of the spending key.

To test that the base node is happy for an UTXO imported in this way to be spent a Cucumber test is provided which imports a UTXO into a wallet and zeroes out the `metadata_signature` and`sender_offset_public_key` and updates the `input_data` and `script_private_key` in the same way as described above. This imported Faucet utxo is then successfully spent to another wallet.

…riScript (tari-project#3139)

## Description
The `wallet_import_utxo` FFI function in LibWallet just used defaults for a number of the new UTXO fields when importing a faucet UTXO. The Faucet UTXO provided by the client is just the spending key and amount. The `metadata_signature` and `sender_offset_public_key` can both remain as default values as they are not used in spending an UTXO.  A Nop script is assumed and the spending key is used as the `script_private_key`. The final update is that the `input_data` it set as the public key of the spending key.

To test that the base node is happy for an UTXO imported in this way to be spent a Cucumber test is provided which imports a UTXO into a wallet and zeroes out the `metadata_signature` and`sender_offset_public_key` and updates the `input_data` and `script_private_key` in the same way as described above. This imported Faucet utxo is then successfully spent to another wallet.

## How Has This Been Tested?
Cucumber test provided

## Checklist:
<!--- Go over all the following points, and put an `x` in all the boxes that apply. -->
* [x] I'm merging against the `development` branch.
* [x] I have squashed my commits into a single commit.

The current architecture of the wallet is that the AppState contains a cache of the current state that the UI uses to draw from and a second instance of the data that is updated in the background when events are received from the wallet services without interfering with drawing. When the background data has been updated by the event monitoring thread it flips a flag telling the UI that the cache has been invalidated so when the drawing is done on a Tick event the UI thread will clone the background data into the cache for future drawing calls.

A problem was found where when a large number of transactions were being processed by the wallet the UI would become unresponsive. The reason for this is that with a large amount of transactions there is quite a lot of AppState that is copied from the background into the UI cache which could take 300-400ms and this cache was being invalidated very often as the transactions are being handled by the wallet services. This would mean that a Cache copy occurred after every single draw cycle and would block the processing of Key events for 300-400ms.

This PR proposes a solution of introducing a cache update cooldown period, initially set to 2 seconds, so that if a cache update has occurred the soonest that the next update can occur is 2 seconds later giving the UI thread time to handle key events. In normal wallet operation state update events do not occur that often so this approach will allow the cache update to occur as soon as the cache is invalidated but will force a fast subsequent update to wait at least 2 seconds. In the mean time the background data can be worked on in the background thread.

<!--- Provide a general summary of your changes in the Title above -->

## Description
<!--- Describe your changes in detail -->
We sometimes find that transactions created by the cucumber transaction builder fail lmdb insertion by duplicate excess. 
This increases the private key range for the private keys increasing the range of the excess. This should decrease duplicate entries. 

## Motivation and Context
<!--- Why is this change required? What problem does it solve? -->
<!--- If it fixes an open issue, please link to the issue here. -->

## How Has This Been Tested?
<!--- Please describe in detail how you tested your changes. -->
<!--- Include details of your testing environment, and the tests you ran to -->
<!--- see how your change affects other areas of the code, etc. -->

## Checklist:
<!--- Go over all the following points, and put an `x` in all the boxes that apply. -->
* [x] I'm merging against the `development` branch.
* [x] I have squashed my commits into a single commit.

<!--- Provide a general summary of your changes in the Title above -->

## Description
<!--- Describe your changes in detail -->
When a transaction is not found on `GetTransactionInfo` the GRPC call will return a transaction with "junk" data including a status that is set to complete. But the not_found flag is set to false, which is also the default GRPC value for boolean. 

This removes the `not_found` flag and adds a status, `not found` to avoid confusion. 

## Motivation and Context
<!--- Why is this change required? What problem does it solve? -->
<!--- If it fixes an open issue, please link to the issue here. -->

## How Has This Been Tested?
<!--- Please describe in detail how you tested your changes. -->
<!--- Include details of your testing environment, and the tests you ran to -->
<!--- see how your change affects other areas of the code, etc. -->

## Checklist:
<!--- Go over all the following points, and put an `x` in all the boxes that apply. -->
* [x] I'm merging against the `development` branch.
* [x] I have squashed my commits into a single commit.

Update proxy.rs

WIP

Added stratum configuration to miner.
Mostly implemented stratum.
Mostly implemented stratum controller.
Partially implemented stratum miner.

Rebased to latest dev

Import PR#3006

Rebased to latest dev and updated version to 0.9.0

Fixed tari_stratum_ffi tests

Clippy and cargo-fmt

Bug fixes

Return blockheader as json object.
Retrieve recipients from params instead of directly from body of request.
Fix bug in GetHeaderByHeight

Update stratum miner to receive blockheader instead of block

clippy

update

Update

Implemented keepalive
Bug fix for transfer results
Implemented stratum error code response handling in tari_mining_node

Rebase fix

Update stratum.rs

Update stratum.rs

Review Comments

Update and Fixes

Added ResumeJob to MinerMessage.
Fixed disconnection bug where miner would not resume solves on reconnect.
Added transcoder_host_address config variable to stop using proxy_host_address as it is already used by mm_proxy, this enables them both to be run simultaneously.

Update cucumber config variables

- protocol notifications now have a set "safety" timeout.
- add log for inbound comms pipeline concurrency usage

A bug was observed that now and then a Coinbase Transaction would not conclude its monitoring with this error:
`ValueNotFound(CompletedTransaction(15645503741743694020))`

This occurred when due to a small network reorg the miner would request a block for the same height. The new request would often have a different amount of fees which would mean this transaction needs to be cancelled in favour of the new transaction. However, with the transaction being cancelled the coinbase monitoring task will come around to checking the DB if the transaction is still there so it can continue to poll the base node and will get the ValueNotFound error. This is correct behaviour so should not have been logged as an error. The error case also means that the TransactionCancelled event is never fired which resulted in the console wallet UI not updating the state of that transaction which left it in the transaction list erroneous.

So this PR handles that “Error” properly and sends the event before ending the coinbase monitoring	task.

increase key length

This PR adds the tari_stratum_ffi library and tari_stratum_transcoder application for use with Miningcore.

This PR also expands tari_mining_node with stratum support to interact with Miningcore.

See here for the Tari implementation in Miningcore:
Source: https://github.com/StriderDM/miningcore/tree/tari
Compare: coinfoundry/[email protected]:tari

Edit: Functional, will need refactoring

…roject#3143)

<!--- Provide a general summary of your changes in the Title above -->

<!--- Describe your changes in detail -->
- protocol notifications now have a set "safety" timeout.
- add log for inbound comms pipeline concurrency usage

<!--- Why is this change required? What problem does it solve? -->
<!--- If it fixes an open issue, please link to the issue here. -->
Reports of inbound messaging being blocked. This will shed some light.
The logs show that a single client node is excessively trying to create multiple
`t/bn-wallet//1` (rpc) sessions.

<!--- Please describe in detail how you tested your changes. -->
<!--- Include details of your testing environment, and the tests you ran to -->
<!--- see how your change affects other areas of the code, etc. -->
Log observed in base node

<!--- Go over all the following points, and put an `x` in all the boxes that apply. -->
* [x] I'm merging against the `development` branch.
* [x] I have squashed my commits into a single commit.

Moved stratum_transcoder config variables to its' own section.
Fixed bug in defaults for stratum_transcoder.
Updated example config and cucumber variable to reflect changes in configuration.
Added stratum mode configuration variables for tari_mining_node in sample config, commented out by default.

…#3146)

## Description
The current architecture of the wallet is that the AppState contains a cache of the current state that the UI uses to draw from and a second instance of the data that is updated in the background when events are received from the wallet services without interfering with drawing. When the background data has been updated by the event monitoring thread it flips a flag telling the UI that the cache has been invalidated so when the drawing is done on a Tick event the UI thread will clone the background data into the cache for future drawing calls.

A problem was found where when a large number of transactions were being processed by the wallet the UI would become unresponsive. The reason for this is that with a large amount of transactions there is quite a lot of AppState that is copied from the background into the UI cache which could take 300-400ms and this cache was being invalidated very often as the transactions are being handled by the wallet services. This would mean that a Cache copy occurred after every single draw cycle and would block the processing of Key events for 300-400ms.

This PR proposes a solution of introducing a cache update cooldown period, initially set to 2 seconds, so that if a cache update has occurred the soonest that the next update can occur is 2 seconds later giving the UI thread time to handle key events. In normal wallet operation state update events do not occur that often so this approach will allow the cache update to occur as soon as the cache is invalidated but will force a fast subsequent update to wait at least 2 seconds. In the mean time the background data can be worked on in the background thread.

## How Has This Been Tested?
Manually Tested

## Checklist:
<!--- Go over all the following points, and put an `x` in all the boxes that apply. -->
* [x] I'm merging against the `development` branch.
* [x] I have squashed my commits into a single commit.

…me height (tari-project#3151)

## Description
A bug was observed that now and then a Coinbase Transaction would not conclude its monitoring with this error:
`ValueNotFound(CompletedTransaction(15645503741743694020))`

This occurred when due to a small network reorg the miner would request a block for the same height. The new request would often have a different amount of fees which would mean this transaction needs to be cancelled in favour of the new transaction. However, with the transaction being cancelled the coinbase monitoring task will come around to checking the DB if the transaction is still there so it can continue to poll the base node and will get the ValueNotFound error. This is correct behaviour so should not have been logged as an error. The error case also means that the TransactionCancelled event is never fired which resulted in the console wallet UI not updating the state of that transaction which left it in the transaction list erroneous.

So this PR handles that “Error” properly and sends the event before ending the coinbase monitoring task.

## How Has This Been Tested?
unit tests

## Checklist:
<!--- Go over all the following points, and put an `x` in all the boxes that apply. -->
* [x] I'm merging against the `development` branch.
* [x] I have squashed my commits into a single commit.

… cucumber test (tari-project#3153)

<!--- Provide a general summary of your changes in the Title above -->

## Description
<!--- Describe your changes in detail -->
Improve the `Verify all coinbases in hybrid mining are accounted for` to be less flaky.
Improved the readability of the test. 
Made the following improvements:
Ensure that the monero merge mining does not mine more blocks than it should.
Rather than check if they are at the same height, check tips.
Due to the network topology, added a wait timer to ensure that the nodes have time to reorg and give the wallets time to invalidate coinbases.

Added in another improvement to the coinbase value selection. 
## Motivation and Context
<!--- Why is this change required? What problem does it solve? -->
<!--- If it fixes an open issue, please link to the issue here. -->

## How Has This Been Tested?
<!--- Please describe in detail how you tested your changes. -->
<!--- Include details of your testing environment, and the tests you ran to -->
<!--- see how your change affects other areas of the code, etc. -->

## Checklist:
<!--- Go over all the following points, and put an `x` in all the boxes that apply. -->
* [x] I'm merging against the `development` branch.
* [x] I have squashed my commits into a single commit.

Bumps [tar](https://github.com/npm/node-tar) from 6.1.0 to 6.1.6.
- [Release notes](https://github.com/npm/node-tar/releases)
- [Changelog](https://github.com/npm/node-tar/blob/main/CHANGELOG.md)
- [Commits](isaacs/node-tar@v6.1.0...v6.1.6)

---
updated-dependencies:
- dependency-name: tar
  dependency-type: indirect
...

Signed-off-by: dependabot[bot] <[email protected]>

<!--- Provide a general summary of your changes in the Title above -->

## Description
Moved stratum_transcoder config variables to its' own section.
Fixed bug in defaults for stratum_transcoder.
Updated example config and cucumber variable to reflect changes in configuration.
Added stratum mode configuration variables for tari_mining_node in sample config, commented out by default.

## Motivation and Context
Cleanup and bugfix

## How Has This Been Tested?
Manual testing

## Checklist:
* [x] I'm merging against the `development` branch.
* [x] I have squashed my commits into a single commit.

<!--- Provide a general summary of your changes in the Title above -->

## Description
<!--- Describe your changes in detail -->
The search-kernel command in the base_node UI currently returns either an error, none or the block containing said kernel. 
The UI interprets a None as a successful command, but the block could not be found due to it being a pruned block. This is incorrect, as the returned block is always a `historical block`. `Historical blocks` can have pruned outputs in them. So when a block is pruned, the base_node will return the block with the information it can fill in, plus all pruned outputs. 

When a kernel is not found in the chain, the search commands returns Ok(None) and the UI now interprets this correctly as the kernel is not found. 

## Motivation and Context
<!--- Why is this change required? What problem does it solve? -->
<!--- If it fixes an open issue, please link to the issue here. -->

## How Has This Been Tested?
<!--- Please describe in detail how you tested your changes. -->
<!--- Include details of your testing environment, and the tests you ran to -->
<!--- see how your change affects other areas of the code, etc. -->

## Checklist:
<!--- Go over all the following points, and put an `x` in all the boxes that apply. -->
* [x] I'm merging against the `development` branch.
* [x] I have squashed my commits into a single commit.

…ests/tar-6.1.6

…-project#3161)

Bumps [tar](https://github.com/npm/node-tar) from 6.1.0 to 6.1.6.
<details>
<summary>Commits</summary>
<ul>
<li><a href="https://github.com/npm/node-tar/commit/9bc1729939eec1c822b528385b1cc513b9888835"><code>9bc1729</code></a> 6.1.6</li>
<li><a href="https://github.com/npm/node-tar/commit/bdf4f5171340b890a62a5e578962ac143d34b3a9"><code>bdf4f51</code></a> fix: properly prefix hard links</li>
<li><a href="https://github.com/npm/node-tar/commit/94b2a740115fdce20f265a029b0404d53c0a18c6"><code>94b2a74</code></a> chore: remove benchmarks from git repo</li>
<li><a href="https://github.com/npm/node-tar/commit/ecaafb4777b7137421f2f0d6f40ab827654f9247"><code>ecaafb4</code></a> update deps</li>
<li><a href="https://github.com/npm/node-tar/commit/bd4691c90478f41b2649a97048199e34927dc046"><code>bd4691c</code></a> 6.1.5</li>
<li><a href="https://github.com/npm/node-tar/commit/d694c4f810d864badf223efa35d24a000d780179"><code>d694c4f</code></a> ci: test on node 16</li>
<li><a href="https://github.com/npm/node-tar/commit/84acbd31288541100910a528e437f901f8012214"><code>84acbd3</code></a> fix(unpack): fix hang on large file on open() fail</li>
<li><a href="https://github.com/npm/node-tar/commit/97c46fcee7e4e7849ea3432086c4537fb6197025"><code>97c46fc</code></a> fix(unpack): always resume parsing after an entry error</li>
<li><a href="https://github.com/npm/node-tar/commit/488ab8c01de69379406d937419fa3e5550e651c0"><code>488ab8c</code></a> chore: WriteEntry cleaner write() handling</li>
<li><a href="https://github.com/npm/node-tar/commit/be89aafd95296e9721e124b77eee7c745e1c1e97"><code>be89aaf</code></a> WriteEntry backpressure</li>
<li>Additional commits viewable in <a href="https://github.com/npm/node-tar/compare/v6.1.0...v6.1.6">compare view</a></li>
</ul>
</details>
<br />


[![Dependabot compatibility score](https://dependabot-badges.githubapp.com/badges/compatibility_score?dependency-name=tar&package-manager=npm_and_yarn&previous-version=6.1.0&new-version=6.1.6)](https://docs.github.com/en/github/managing-security-vulnerabilities/about-dependabot-security-updates#about-compatibility-scores)

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting `@dependabot rebase`.

[//]: # (dependabot-automerge-start)
[//]: # (dependabot-automerge-end)

---

<details>
<summary>Dependabot commands and options</summary>
<br />

You can trigger Dependabot actions by commenting on this PR:
- `@dependabot rebase` will rebase this PR
- `@dependabot recreate` will recreate this PR, overwriting any edits that have been made to it
- `@dependabot merge` will merge this PR after your CI passes on it
- `@dependabot squash and merge` will squash and merge this PR after your CI passes on it
- `@dependabot cancel merge` will cancel a previously requested merge and block automerging
- `@dependabot reopen` will reopen this PR if it is closed
- `@dependabot close` will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
- `@dependabot ignore this major version` will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
- `@dependabot ignore this minor version` will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
- `@dependabot ignore this dependency` will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)
- `@dependabot use these labels` will set the current labels as the default for future PRs for this repo and language
- `@dependabot use these reviewers` will set the current reviewers as the default for future PRs for this repo and language
- `@dependabot use these assignees` will set the current assignees as the default for future PRs for this repo and language
- `@dependabot use this milestone` will set the current milestone as the default for future PRs for this repo and language

You can disable automated security fix PRs for this repo from the [Security Alerts page](https://github.com/tari-project/tari/network/alerts).

</details>

…3148)

- An "FundsPending" error returned from the coin split step will now be handled
  gracefully and not stop the test
- Wallet A will monitor transactions to be at least broadcast when sending
  one-sided transactions to wallet B before mining will commence

<!--- Provide a general summary of your changes in the Title above -->

## Description
Fixed _"Ramped Stress Test"_ to be less flaky:
- A "FundsPending" error returned from the coin split step will now be handled gracefully and not stop the test

Fixed _"Wallet sending and receiving one-sided transactions"_ to be less flaky:
- Wallet A will monitor transactions to be at least broadcast when sending one-sided transactions to wallet B before mining will commence

## Motivation and Context
Cucumber tests were flaky.

## How Has This Been Tested?
Running the integration tests in question.

## Checklist:
<!--- Go over all the following points, and put an `x` in all the boxes that apply. -->
* [X] I'm merging against the `development` branch.
* [X] I have squashed my commits into a single commit.

This PR fixes an issue where bottled up tokio interval events are fired
successively for the edge case where a computer wakes up from sleep. This
was evident in the UTXO scanning service where many many UTXO scanning tasks
would be started in parallel afterwards instead of only one.

…3160)

…ari-project#3167)

<!--- Provide a general summary of your changes in the Title above -->

## Description
<!--- Describe your changes in detail -->
Changed the monero URL address used by the cucumber test from: `http://monero-stagenet.exan.tech:38081` to `http://3.104.4.129:18081/`

## Motivation and Context
<!--- Why is this change required? What problem does it solve? -->
<!--- If it fixes an open issue, please link to the issue here. -->

## How Has This Been Tested?
<!--- Please describe in detail how you tested your changes. -->
<!--- Include details of your testing environment, and the tests you ran to -->
<!--- see how your change affects other areas of the code, etc. -->

## Checklist:
<!--- Go over all the following points, and put an `x` in all the boxes that apply. -->
* [ ] I'm merging against the `development` branch.
* [ ] I have squashed my commits into a single commit.

Added exception handling to gRPC methods submitting transactions in
cucumber integration test steps. Async timing is not always favourable
to conclude a transaction; retrying a transaction if it returns an
error is important for test robustness.

)


<!--- Provide a general summary of your changes in the Title above -->

## Description
Added exception handling to gRPC methods submitting transactions in cucumber integration test steps. Async timing is not always favourable to conclude a transaction; retrying a transaction if it returns an error is important for test robustness.

## Motivation and Context
See above.

## How Has This Been Tested?
Running cucumber tests locally

## Checklist:
<!--- Go over all the following points, and put an `x` in all the boxes that apply. -->
* [X] I'm merging against the `development` branch.
* [X] I have squashed my commits into a single commit.

Fixed network bug in walletProcess.
Fixed grpcPort bug in walletProcess for custom grpc address.
Updated network in washing machine.
Added routing mechanism.
Added excludeTestEnvrs.

Added notifications via web hook if url is supplied

Update washing_machine.js

Reduced output noisiness

<!--- Provide a general summary of your changes in the Title above -->

## Description
<!--- Describe your changes in detail -->
Ban peer if block validation fails during block body sync

## Motivation and Context
<!--- Why is this change required? What problem does it solve? -->
<!--- If it fixes an open issue, please link to the issue here. -->
When this error is encountered, the peer sent an invalid block body given the current header chain.  
`DEBUG Block sync failed: Block validation failed: Block validation error: Mismatched MMR roots`
The node should ban the peer. Previously, the node would encounter this, then retry the same peer,
rinse and repeat - preventing the node from syncing.

## How Has This Been Tested?
<!--- Please describe in detail how you tested your changes. -->
<!--- Include details of your testing environment, and the tests you ran to -->
<!--- see how your change affects other areas of the code, etc. -->
Not explicitly tested - fairly basic change.

## Checklist:
<!--- Go over all the following points, and put an `x` in all the boxes that apply. -->
* [x] I'm merging against the `development` branch.
* [x] I have squashed my commits into a single commit.

## Description
Integration test for wallet commands. It doesn't cover all possible scenarios, but it does cover every command.

Adds an RPC client session pool to efficiently maintain multiple shared
RPC sessions on the p2p network.

Potentially fixes GRPC connection issues we've been having

…me (tari-project#3152)


<!--- Provide a general summary of your changes in the Title above -->

## Description
<!--- Describe your changes in detail -->
Adds an RPC client session pool to efficiently maintain multiple shared
RPC sessions on the p2p network.

## Motivation and Context
<!--- Why is this change required? What problem does it solve? -->
<!--- If it fixes an open issue, please link to the issue here. -->
Wallet currently establishes one or more RPC sessions per transaction. At times, during stress tests these
sessions are opened and closed many times. Each time an RPC sessions is established, protocol negotiation 
and RPC handshakes must occur. These components can make use of the shared RPC client pool 
to more efficiently and easily manage multiple sessions without creating situations where the target peer is
thrashed with 10s of thousands of sessions in a stress test situation.   

Implementing this in the wallet is TODO.

Some RPC test utilities were moved around to make them useful to other tests, which has added some LOC

## How Has This Been Tested?
<!--- Please describe in detail how you tested your changes. -->
<!--- Include details of your testing environment, and the tests you ran to -->
<!--- see how your change affects other areas of the code, etc. -->
Extensive unit tests

## Checklist:
<!--- Go over all the following points, and put an `x` in all the boxes that apply. -->
* [x] I'm merging against the `development` branch.
* [ ] I have squashed my commits into a single commit.

## Description
Fixes the panic during resize.

## How Has This Been Tested?
Manually, and also added a cargo test.

## Checklist:
* [x] I'm merging against the `development` branch.
* [x] I have squashed my commits into a single commit.

Adds a service responsible for wallet connectivity. This service
is responsible for and abstracts any complexity in the management of
the base node connections and RPC session management.

This PR makes use of this service in the base node montoring service but
does not "plumb" the WalletConenctivityService into the protocols. This
is left as a TODO, but we should expect this to remove many lines of
code and greaty simplify these protocols by removing the budren of
connection management in the various wallet components.

A number of simplifications on the peer connection and substream code,
debatably reducing places that bugs could hide.

This PR adds two changes to the way SAF messages are handled to fix two subtle bugs spotted while developing cucumber tests.

The first issue was that when a Node propagates a SAF message it was storing to other nodes in its neighbourhood the broadcast strategy it was using only chose from currently connected base nodes. This meant that if the Node had an active connection to a Communication Client (wallet) it would not just directly send the SAF message to that client but to other base nodes in the network region. This meant that the wallet would only receive new SAF message when it actively requested them on connection even though it was directly connected to the node.

This PR adds a new broadcast strategy called `DirectOrClosestNodes` which will first check if the node has a direct active connection and if it does just send the SAF message directly to its destination.

The second issue was a subtle problem where when a node starts to send SAF messages to a destination it would remove the messages from the database based only on whether the outbound messages were put onto the outbound message pipeline. The problem occurs when the TCP connection to that peer is actually broken the sending of those messages would fail at the end of the pipeline but the SAF messages were already deleted from the database.

This PR changes the way SAF messages are deleted. When a client asks a node for SAF message it will also provide a timestamp of the most recent SAF message it has received. The Node will then send all SAF messages since that timestamp that it has for the node and will delete all SAF messages from before the specified Timestamp.  This serves as a form of Ack that the client has received the older messages at some point and they are no longer needed.

<!--- Provide a general summary of your changes in the Title above -->

## Description
<!--- Describe your changes in detail -->
Adds a service responsible for wallet connectivity. This service
is responsible for and abstracts any complexity in the management of
the base node connections and RPC session management.

This PR makes use of this service in the base node montoring service but
does not "plumb" the WalletConenctivityService into the protocols. This
is left as a TODO, but we should expect this to remove many lines of
code and greaty simplify these protocols by removing the budren of
connection management in the various wallet components.

A number of simplifications on the peer connection and substream code,
debatably reducing places that bugs could hide.

## Motivation and Context
<!--- Why is this change required? What problem does it solve? -->
<!--- If it fixes an open issue, please link to the issue here. -->
Follow on from tari-project#3152, making use of the pool in the wallet base node monitoring. The rest of the protocols should follow. 

## How Has This Been Tested?
<!--- Please describe in detail how you tested your changes. -->
<!--- Include details of your testing environment, and the tests you ran to -->
<!--- see how your change affects other areas of the code, etc. -->
Extensive service unit tests
Existing tests pass

Washing machine test on local wallet, with the broadcast protocol modified to use the wallet connectivity 
Base node RPC sessions max out at 10 each (2 wallets connected to same base node) even when pushing through 426 transactions.
![image](https://user-images.githubusercontent.com/1057902/128175630-52617736-f71f-4865-a915-6d6c9b00e8d5.png)

Manually tested wallet connectivity states (Connecting -> Online | Connecting -> Offline | Connecting -> Online -> Offline -> Connecting -> Online)

## Checklist:
<!--- Go over all the following points, and put an `x` in all the boxes that apply. -->
* [x] I'm merging against the `development` branch.
* [x] I have squashed my commits into a single commit.

…ri-project#3156)

<!--- Provide a general summary of your changes in the Title above -->

## Description
<!--- Describe your changes in detail -->
Found that the test: Massive multiple reorg failed because the block height of 5 had an equal difficulty of one of height 10. https://35459-136459099-gh.circle-artifacts.com/0/integration_tests/temp/reports/cucumber_report.html
Simplified the test somewhat. 
Changed it to ensure that we would always end up with a single chain. 

## Motivation and Context
<!--- Why is this change required? What problem does it solve? -->
<!--- If it fixes an open issue, please link to the issue here. -->

## How Has This Been Tested?
<!--- Please describe in detail how you tested your changes. -->
<!--- Include details of your testing environment, and the tests you ran to -->
<!--- see how your change affects other areas of the code, etc. -->

## Checklist:
<!--- Go over all the following points, and put an `x` in all the boxes that apply. -->
* [x] I'm merging against the `development` branch.
* [x] I have squashed my commits into a single commit.

<!--- Provide a general summary of your changes in the Title above -->

## Description
<!--- Describe your changes in detail -->
When requesting pruned data on base_node, the node would panic as it tried to provide pruned data. 
Removed this panic and changed requests for `TransactionOutputs` to `PrunedOutputs` so that callee functions can decide what to do with the data. 
Fixed ignored pruned unit test. 
Added in cucumber test to prove nodes cant sync from pruned nodes and neither panics. 

## Motivation and Context
<!--- Why is this change required? What problem does it solve? -->
<!--- If it fixes an open issue, please link to the issue here. -->

## How Has This Been Tested?
<!--- Please describe in detail how you tested your changes. -->
<!--- Include details of your testing environment, and the tests you ran to -->
<!--- see how your change affects other areas of the code, etc. -->

## Checklist:
<!--- Go over all the following points, and put an `x` in all the boxes that apply. -->
* [x] I'm merging against the `development` branch.
* [x] I have squashed my commits into a single commit.

Non-zero error code on failure and return more information about the error.
Adds logfile output for processes

(1) When using the wallet CLI mode, the wallet is not always in the correct
    state to send transactions, depending on the last known metadata status
    from the previously connected base node. This PR introduces exception
    handling for wallet CLI commands so that it will automatically retry
    to execute the command if it fails.
    A follow-up PR should let the wallet wait for a base node connection
    before it executes certain commands.
(2) Added a new test step to explicitly test transaction statuses in the
    wallet.
(3) Fixed the UTXO scanning service so it would not go into an infinite loop
    trying to scan UTXOs if the blockchain does not have any UTXOs yet.
(4) Fixed an erroneous error return in the output manager service.

Fix typos

…oject#3164)

## Description

This PR adds two changes to the way SAF messages are handled to fix two subtle bugs spotted while developing cucumber tests.

The first issue was that when a Node propagates a SAF message it was storing to other nodes in its neighbourhood the broadcast strategy it was using only chose from currently connected base nodes. This meant that if the Node had an active connection to a Communication Client (wallet) it would not just directly send the SAF message to that client but to other base nodes in the network region. This meant that the wallet would only receive new SAF message when it actively requested them on connection even though it was directly connected to the node.

This PR adds a new broadcast strategy called `DirectOrClosestNodes` which will first check if the node has a direct active connection and if it does just send the SAF message directly to its destination.

The second issue was a subtle problem where when a node starts to send SAF messages to a destination it would remove the messages from the database based only on whether the outbound messages were put onto the outbound message pipeline. The problem occurs when the TCP connection to that peer is actually broken the sending of those messages would fail at the end of the pipeline but the SAF messages were already deleted from the database.

This PR changes the way SAF messages are deleted. When a client asks a node for SAF message it will also provide a timestamp of the most recent SAF message it has received. The Node will then send all SAF messages since that timestamp that it has for the node and will delete all SAF messages from before the specified Timestamp.  This serves as a form of Ack that the client has received the older messages at some point and they are no longer needed.

## How Has This Been Tested?
Unit tests have been updated to test this functionality.

## Checklist:
<!--- Go over all the following points, and put an `x` in all the boxes that apply. -->
* [x] I'm merging against the `development` branch.
* [x] I have squashed my commits into a single commit.

…project#3179)

<!--- Provide a general summary of your changes in the Title above -->

## Description
<!--- Describe your changes in detail -->
The unit test had 2 edge cases:

1. When the transaction had no change, the master_key index should be 0 and not 1. 
2. Inside of the builder we had an edge case of one check being `>=` while the next check being `>` which resulted in the tx builder thinking it did not have enough funds

## Motivation and Context
<!--- Why is this change required? What problem does it solve? -->
<!--- If it fixes an open issue, please link to the issue here. -->

## How Has This Been Tested?
<!--- Please describe in detail how you tested your changes. -->
<!--- Include details of your testing environment, and the tests you ran to -->
<!--- see how your change affects other areas of the code, etc. -->

## Checklist:
<!--- Go over all the following points, and put an `x` in all the boxes that apply. -->
* [x] I'm merging against the `development` branch.
* [x] I have squashed my commits into a single commit.

Adds optional field to config for tari_mining_node to allow the miner to be named when using the stratum configuration.

Updated successful server connection status from warn to info.