P2P sync ahead while applying received blocks

[heifner]

Continue syncing the next sync-fetch-span while apply current range of synced blocks. It is prevented from running too far ahead of head by sync-fetch-span. It does queue up to double the amount of blocks during syncing than before this PR.

Before this PR:

[ sync blks A ]             [ sync blks B ]             [ sync blks C ]
    [ apply blocks A.. ... ]    [ apply blocks B.. ... ]    [ apply blocks C.. ... ]

After this PR:

[ sync blks A ][ sync blks B ][ sync blks C ]       [ sync blks D ]         [ sync blks E ]
    [ apply blocks A.. ... ][ apply blocks B.. ... ][ apply blocks C.. ... ][ apply blocks D.. ... ]

On my machine syncing into EOS mainnet, I was able to maintain 100% CPU while syncing.

Includes a fix for excessive handshake messages during syncing.

Resolves #1072

[greg7mdp]

Why do we use c->peer_lib_num at line 1851, and last_handshake_recv.last_irreversible_block_num 8 lines below?

[heifner]

Why do we use c->peer_lib_num at line 1851, and last_handshake_recv.last_irreversible_block_num 8 lines below?

peer_lib_num is only valid to access from the connection strand, so can't use it on line 1859.