Improve the transfer-ID timeout

A while ago, while we were working toward the current beta specification, @scottdixon pointed out that the transfer-ID timeout is an odd item because it brings a rather arbitrarily-chosen default parameter into the specification while also requiring users to tune it per use case. At the time we didn’t have any better ideas so we left it as-is. I think I do have a better idea now.

In Cyphal/CAN, everything stays as-is. In all other transports, which happen to be using very wide 64-bits transfer-ID counters, we set the initial transfer ID value randomly instead of zero initialization. The random values should differ across power cycles. For transfer senders, this is the only change: random 64-bit integers instead of zeros.

For transfer receivers, we amend section 4.1.4.2 such that transfers whose transfer-IDs are separated by more than one million counts are also considered unique (this also covers the 64-bit wraparound). The probability of randomly picking a new 64-bit value that falls into a given million-count span is about one in 18 trillion. For backward compatibility, the transfer-ID timeout rule stays as well, but in the implementation libraries the timeout will be fixed initially at 2 seconds (as advised in the specification) and it will no longer be user-configurable (simpler API). Eventually, we might consider increasing this value in implementations to ~1 minute.

This is also why all new transport specs should prefer 64-bit transfer-ID values.

(FYI this is not the big announcement I promised a few days ago, just a quick remark)

The problem is we add a requirement that the hardware provides TRNG circuitry which is not always the case or, when available, is not always made available in some BSPs. I’m not sure I can support that constraint.

We can keep the current logic then but also add the condition that if the transfer ID jumps back by more than some large number, it is to be considered unique. This doesn’t affect nodes without RNG.