Update Consensus Close Time Algorithms

[movitto]

See #2932 and #2952. This issue is to explore the algorithms behind the consensus close time negotation / voting.

Currently the close time is generated through an averaging of the current votes. Other possibilities (as discussed in #2952) include generating from the:

• median value
• the "most popular" value
• generating from the distribution of close times
• other possibilities

[nbougalis]

I think that a very useful first step here is to have a tool that, for every consensus round, collects the proposed close time from as many validators as possible and that we do this for a minimum of a week.

We can then analyze this data set and better understand the behavior of the network, as well as run simulations that will help us understand which measure of central tendency is best.

[movitto]

👍 Makes sense. I can also see this being useful if eventually integrated into the XRPL itself allowing for nodes to base their votes on different criteria. For example the default could be averaging / median / etc as deduced through this first step, but other nodes could delegate the decision behind their vote to an external monitoring instance (perhaps a dedicated node in a cluster), while others could do it in a different way alltogether. Would increase the complexity a bit but would also facilitate XRPL being the ultimate pluggable BlockChain!