Improve sv2 cpuminer

[Fi3]

Add a nicer user interface to the sv2 cpuminer with help messages. Add noise to the cpuminer.

This is the output of cargo run -- --help

Usage: mining-device [OPTIONS] --address-pool <ADDRESS_POOL>

Options:
  -p, --pubkey-pool <PUBKEY_POOL>    Pool pub key, when left empty the pool certificate is not checked
  -i, --id-device <ID_DEVICE>        Sometimes used by the pool to identify the device
  -a, --address-pool <ADDRESS_POOL>  Address of the pool in this format ip:port or domain:port
      --handicap <HANDICAP>          This value is used to slow down the cpu miner, it rapresents the number of micro-seconds that are awaited between one hashes, default is 0 [default: 0]
  -h, --help                         Print help
  -V, --version                      Print version

[plebhash]

I see this is using clap for CLI, while all other roles crates do not.
Was there any specific reason not to use clap there? Would it be desirable to use clap on roles implementations?

For context, see #813 and #814

[plebhash]

ABC could be made into a CLI arg?

[Fi3]

yep I will do

[lorbax]

this dbg! is supposed to be here?

[lorbax]

I reviewed the code and LGTM.
This PR basically introduces two things: noise encrypted connections and command line arguments (with the aid of clap library). The first is easy to test, because it just works.
For testing the second, I launched the pool with local TP and I launched the mining_device (where the pool-pubkey is retrieved from pool's config)

cargo run -- --pubkey-pool 9auqWEzQDVyd2oe1JVGFLMLHZtCo2FFqZwtKA5gd9xbuEu7PH72 --address-pool 127.0.0.2:34254

I also tested the --address option, by launching the pool listening on a different address listen_address = "127.0.0.2:34254" and the mining device

 cargo run -- --pubkey-pool 9auqWEzQDVyd2oe1JVGFLMLHZtCo2FFqZwtKA5gd9xbuEu7PH72 --address-pool 127.0.0.2:34254

which works as expected.
Similarly, all the other options works (-V and --help), in particular --id-user

2024-03-30T18:04:59.209254Z  INFO roles_logic_sv2::handlers::mining: Received OpenStandardMiningChannel from: pippo with id: 10

[Sjors]

Thanks for opening this! Added to my test list...

[Sjors]

I was able to mine a block!

Followup suggestions (feel free to merge this first, if it's holding back other things):

Use all CPU threads (currently only uses 1).

Rather than --handicap I would prefer being able to set a difficulty target, like the --nbits argument for Bitcoin Core's signet miner: https://github.com/bitcoin/bitcoin/blob/master/contrib/signet/README.md (this even messes with the timestamps to achieve the desired difficulty adjustments)

Perhaps simpler:

• a way to set the max hash rate
• optionally have it wait for x (default 10) minutes before mining the next block

However that can wait for a followup.

[Sjors]

Measuring

[Sjors]

For the second block (on a custom signet) I'm getting errors:

2024-04-05T11:02:30.047785Z  INFO roles_logic_sv2::handlers::template_distribution: Received NewTemplate with id: 2, is future: true
2024-04-05T11:02:30.047829Z  INFO roles_logic_sv2::handlers::template_distribution: Received SetNewPrevHash for template: 2
2024-04-05T11:05:21.072403Z ERROR roles_logic_sv2::channel_logic::channel_factory: Share does not meet any target: Standard((SubmitSharesStandard { channel_id: 1, sequence_number: 2, job_id: 2, nonce: 360646192, ntime: 1712315010, version: 536870912 }, 0))
2024-04-05T11:08:48.166951Z ERROR roles_logic_sv2::channel_logic::channel_factory: Share does not meet any target: Standard((SubmitSharesStandard { channel_id: 1, sequence_number: 3, job_id: 2, nonce: 789285428, ntime: 1712315010, version: 536870912 }, 0))