Nomination: do not vote for new values after confirming a candidate

[marta-lokhova]

Resolves #3523

• Cancel the nomination timer as soon as we have a candidate value. Turn nominate into a no-op when a node confirmed a candidate (just in case it ever gets called outside of the timer).
• add a metric to count how many values are referenced per consensus round. This is done at the slot purge time by counting referenced tx sets in the cache, so this way we know how many values we had to pull. Note that this metric includes value from self as well, even though sometimes the locally generated value might not actually be propagated to the network. If this is an issue, I can add an extra condition to count the local value only if the node actually nominated. Or we can move the cache population call (addTxSet) to when the node actually nominates its local value (but this might cause the node to pull the tx set it generated locally anyway)

[hidenori-shinohara]

The change looks good to me! I had one small question about logging.

[nano-o]

This makes sense to me at a high level. As I understand it, this applies to voting only, and we should keep accepting and confirming values even if we have a candidate already.

[hidenori-shinohara]

LGTM!

This makes sense to me at a high level. As I understand it, this applies to voting only, and we should keep accepting and confirming values even if we have a candidate already.

Yeah, that's how I understood it too.

[MonsieurNicolas]

I don't think this is a clean data source:

• txset cache is a cache -> there is no guarantee that you'll find all entries
• as we're counting when slots are evicted, there is a higher chance that eviction took place
• more noise may be added if multiple slots are purged at once

There is a function logQuorumInformation that seems to be a better place for this kind of tracking: it's only called when externalizing the latest slot, and with a ~fixed window to allow for messages to propagate.
I think that you could combine something like processCurrentState and getTxSetHashes to build a set of unique values referenced by that slot.

[marta-lokhova]

Yeah, I think the initial idea was to get an estimate on how many values the node is processing per ledger, which included values we pulled but didn't record (if an envelope got rejected, for example). I agree that looking at the cache can be noisy, though in this case eviction is extremely unlikely (the cache is sufficiently big, as I'm assuming we want to be able to answer queries about recent ledgers). That being said, I think a metric for values propagated network-wide makes more sense here. I updated the code based on your suggestion.

[MonsieurNicolas]

r+ 74a672e