It seems p2p-compactblocks.py fails randomly

From: https://travis-ci.org/bitcoin/bitcoin/jobs/163788152 from #8841
The PR is trivial and totally unrelated to compact block

```
p2p-compactblocks.py:
Initializing test directory /tmp/test3yd_2q3h/2
start_node: bitcoind started, waiting for RPC to come up
start_node: RPC succesfully started
MiniNode: Connecting to Bitcoin Node IP # 127.0.0.1:11016
Testing SENDCMPCT p2p message... 
Testing compactblock headers and shortIDs are correct...
Assertion failed: 
Stopping nodes
Not cleaning up dir /tmp/test3yd_2q3h/2
Failed
stderr:
  File "/home/travis/build/bitcoin/bitcoin/qa/rpc-tests/test_framework/test_framework.py", line 151, in main
    self.run_test()
  File "/home/travis/build/bitcoin/bitcoin/build/../qa/rpc-tests/p2p-compactblocks.py", line 614, in run_test
    self.test_compactblock_construction()
  File "/home/travis/build/bitcoin/bitcoin/build/../qa/rpc-tests/p2p-compactblocks.py", line 264, in test_compactblock_construction
    assert(self.test_node.last_cmpctblock is not None)
Pass: False, Duration: 7 s
```

arith_uint256 nLastPreciousChainwork = 0;
    /**
     * Sources of received blocks, saved to be able to send them reject
     * messages or ban them when processing happens afterwards. Protected by
     * cs_main.
     */
    map<uint256, NodeId> mapBlockSource;
    /**
     * Filter for transactions that were recently rejected by
     * AcceptToMemoryPool. These are not rerequested until the chain tip
     * changes, at which point the entire filter is reset. Protected by
     * cs_main.
     *
     * Without this filter we'd be re-requesting txs from each of our peers,
     * increasing bandwidth consumption considerably. For instance, with 100
     * peers, half of which relay a tx we don't accept, that might be a 50x
     * bandwidth increase. A flooding attacker attempting to roll-over the
     * filter using minimum-sized, 60byte, transactions might manage to send
     * 1000/sec if we have fast peers, so we pick 120,000 to give our peers a
     * two minute window to send invs to us.
     *
     * Decreasing the false positive rate is fairly cheap, so we pick one in a
     * million to make it highly unlikely for users to have issues with this
     * filter.
     *
     * Memory used: 1.3 MB
     */
    std::unique_ptr<CRollingBloomFilter> recentRejects;
    uint256 hashRecentRejectsChainTip;