Avoid unnecessary "Synchronizing blockheaders" log messages #16774

Fixes #16773

I'm not entirely sure why 16773 happend, but probably due to headers fallback in a compact block.

However, this PR should fix it and should have been included in #15615.

ACK dcc448e3d2b97f7e4e23f5ed174762cec3530306

The extra messages appear when we receive a headers message:

2019-09-03T05:57:30Z ProcessNewBlock
2019-09-03T05:57:30Z NotifyHeaderTip: pindexHeader->height: 593016
2019-09-03T05:57:30Z ProcessMessage: NetMsgType::HEADERS
2019-09-03T05:57:30Z ProcessHeadersMessage
2019-09-03T05:57:30Z ProcessNewBlockHeaders
2019-09-03T05:57:30Z NotifyHeaderTip: pindexHeader->height: 593016
2019-09-03T05:57:30Z Synchronizing blockheaders, height: 593016 (~100.00%)
2019-09-03T05:57:30Z ProcessNewBlock
2019-09-03T05:57:30Z NotifyHeaderTip: pindexHeader->height: 593016

Adjusting NotifyHeaderTip to return a bool, and using that to determine the Synchronizing blockheaders logging seems ok, and aligns this logging with other header tip notifications (although this only logs during IBD).

The other callers of NotifyHeaderTip (ProcessNewBlock and LoadExternalBlockFile) do not use the return value.

ACK dcc448e3d2b97f7e4e23f5ed174762cec3530306 ; code review only, haven't compiled or tested.

I'm not entirely sure why 16773 happend, but probably due to headers fallback in a compact block.

I think it's that you only choose a couple of peers for compact blocks, and then the rest will send you a headers message instead when a new block is found, which will then trigger ProcessNewBlockHeaders; so if your node is down for a while, when you start back up you'll do a header sync and get a message about the new current tip, then you'll set yourself into IBD to catch back up, and if more new blocks come in while you're doing that, you'll get a log message for each new block for each non-compact-block peer you're connected to.

After this patch I think you should still get a single log message for each new block discovered by the network while you're in IBD. If IBD takes 24 hours, that might be an additional 144 log messages, so that doesn't seem too crazy.

ACK dcc448e3d2b97f7e4e23f5ed174762cec3530306.

utACK dcc448e3d2b97f7e4e23f5ed174762cec3530306. Went and read how pindexBestHeader is handled and this code looks correct (worst case it breaks a LogPrint, so whatever). I also ran into this on #16762.

Thanks!