Make the number of validators mutable during chain lifetime

[roman-khimov]

Right now ValidatorsCount sets proper CN count for the whole network lifetime which is acceptable for most public networks, but doesn't fit well some of NeoFS scenarios (growing a network from one node to many of them). Therefore we need to make it possible to change it.

An obvious solution is just an extension of the configuration file, like ValidatorsCount: {height: number, height: number,...}, similar to Legacy's MaxTransactionsPerBlock or FreeGasLimit setting. Easy to implement, but it requires configuration file update on all nodes.

The other option is going through Policy or other special contract. Committee-signed transactions are always good, but it's a separate mechanism and it contradicts the scheme we have now, so maintaining this functionality (protocol extension) would be rather costly.

[fyrchik]

Things that should be taken into account:

1. Real committee is updated once in a while (the performance optimization from af1651941). DBFT should probably see the updated view on validator number when the committee is updated. Otherwise reward calculations should be altered somehow (it is not obvious how).
2. SecondsPerBlock should be altered too. As we could see in benchmarks it can heavily influence TPS when there are many validators.

[roman-khimov]

1. It can be made a part of election process, delaying update for committee number of blocks is not a problem (still, it's easier to do that with configuration file).
2. SecondsPerBlock just requires a configuration on all CNs, other nodes don't care much.

[roman-khimov]

It also affects these things:

• getversion RPC response It's supposed to be static (as protocol configuration) and clients can cache the value they get initially for their purposes.
• tx resend thresholds Initialized once per node lifetime currently, not something critical, but still affecting network's operation.
• committee and validators derived from the configuration ("standby")
• Notary contract's MaxNotValidBeforeDelta calculation Doesn't seem to be critical, but at the moment of switch it can act wrong unless the switch time is known in advance.
• consensus/voting Kinda the most obvious thing, but given the way our voting works there is at least also a question of how to handle the number of voters going below 20%. Normally standby list is used in this case, but it's a standby list and extending it means changing network configuration.

The other thing to keep in mind is that we have a committee which technically can be of different size than CN list. Usually it's taken from the configuration file, but the number of keys there is not specified explicitly, so changing it requires additional configuration option as well.

Updating the number of validators via the configuration file solves almost all of these problems (except for getversion), while keeping it in the contract is not easy. Going through the contract we'll need to keep "excessive" standby validators nearby and we'll have to change some internal parameters on the go (without node restart). Legacy voting was somewhat more flexible wrt this issue.

Unless we completely drop the N3 voting ("private FS mode") we better extend the configuration file format and update configs on all nodes. This way it'll at least not require additional switches (of which we have many already) and the extension itself will be completely possible.