Proto, baker: use deterministic nonces where available

Context

Bakers sometimes lose track of their baking nonces (for instance, when switching to a new instance). This is, per @Ochem, a common enough problem that it causes loss of rewards for many actual users. Among the solutions discussed was to use deterministic nonces for baking. Previously, when deterministic nonces were considered (e.g. in !1245 (closed)), they were rejected for performance reasons. This MR includes a performance hack to reduce the number of nonce computations on Ledger devices to a small enough number to prevent missed blocks.

Manually testing the MR

So far, I've manually tested with tezos-k8s with the default signer back-end (which I guess is unencrypted, since nothing asked me for a password), and that works. To test, make the following change to tezos-k8s:

--- a/charts/tezos/scripts/baker.sh
+++ b/charts/tezos/scripts/baker.sh
@@ -16,6 +16,8 @@ else
     extra_args="--liquidity-baking-toggle-vote on --votefile /etc/tezos/per_block_votes.json"
 fi
 
+extra_args="$extra_args --baking-nonce-mode 1"
+
 my_baker_account="$(cat /etc/tezos/baker-account )"

Then, after a cycle, stop and start the baker. Ensure that there is no nonces file present, and that the baker continues to send nonces.

I also added a tezt test for deterministic nonces.

I also tested that the ledger baking app supports deterministic nonces for all flavors of key:

./tezos-client generate nonce for ledger_novalis_p256 from deadbeef

outputs some nonce value, and if I run it again with the same args, I get the same value, and if I run it with a different seed, I get a different value.

The way nonce generation on ledger goes is: First, the private key is used to sign a fixed value. Then that signature is used as the key for hmac of the seed. It may on first glance seem surprising that tz2 and tz3 keys can produce deterministic nonces, since their signatures are not, by default, deterministic. But looking at the ledger code, it implements RFC6979, which gives deterministic signatures. It would, in theory, be possible to verify this by using:

./tezos-client -p ProtoALphaALphaALphaALphaALphaALphaALphaALphaDdp3zK sign bytes 0xdeadbeef for some_ledger_key

(which uses the same signing code) but that doesn't actually work: the ledger baking app refuses to sign arbitrary bytes. But code inspection shows only one code path that calls cx_ecdsa_sign, and it always uses CX_RND_RFC6979.

Checklist

• Document the interface of any function added or modified (see the coding guidelines)
• Document any change to the user interface, including configuration parameters (see node configuration)
• Provide automatic testing (see the testing guide).
• For new features and bug fixes, add an item in the appropriate changelog (docs/protocols/alpha.rst for the protocol and the environment, CHANGES.rst at the root of the repository for everything else).
• Select suitable reviewers using the Reviewers field below.
• Select as Assignee the next person who should take action on that MR