Reduce the chain block time from 3s to 2s

The following consideration are the result of a chat with @dan and @gandalf

Why

This change will not solve a specific problem, but everything happening on Hive will be snappier and feel faster to the user. Faster actions on social frontends, faster battles on splinterlands, faster feedback, ...faster everything. Probably also Hivemind will be faster to receive updates.

Things to consider

• There are almost certainly some things that assume a 3s block time, so it wouldn't be safe to simply change a constant, recompile and launch with new nodes. The other issue is that a decreased block time increases the chance for missed blocks and forks due to transmission latency.

• Higher traffic and block size (block size is a witness parameter, we can have much larger blocks 1M and much more filled...). It's easy to meet latency requirements while dealing with blocks which max_size is set to a minimum (65535)

• One downside of more blocks is increased overhead associated with meta data for the blocks. So if you have a lot of blocks without much transaction data, your chain can be inefficient with respect to storage.

• Increasing the frequency will probably lower the amount of transactions is each block, so processing a single block will be faster (assumed the same amount of tx/day)

Next steps

Before evaluating the change is important to setup a testnet that can be used to perform some tests in a real world scenario. This means having multiple nodes with real world latency and with a good amount of transactions to process (real traffic).

This testnet can be set up with 1s block time first, then start backing off the time, to see how things change, if too many blocks are being missed.

Other points to consider at a later stage

Hivemind will probably need some work to see if we are referring to block time to compute stuff, and a lot of troubles with much more frequent forks (but fork handling in hivemind is yet another subject to look at)