If node 0 is sufficiently fast to announce its block to node 1,
node 1 might already have the block by the time the
node_sync_via_rpc loop gets around to node 1, resulting in the
submitblock result "duplicate-inconclusive" as node 1 has the block,
but prefers an alternate chain.

In order to do this, we must call ActivateBestChain prior to
responding getdata requests for blocks which we announced using
compact blocks.

For getheaders responses we dont need code changes, but do note
that we must reset the bestHeaderSent so that the SendMessages call
re-announces the header in question.

While we could do something smarter for getblocks, calling
ActivateBestChain is simple and more obviously correct, instead of
doing something more similar to getheaders.

See-also the BIP clarifications at
bitcoin/bips#486

There is still a call to ActivateBestChain with cs_main if a peer
requests the block prior to it being validated, but this one is
more specifically-gated, so should be less of an issue.