Reported here: https://github.com/bitcoin/bitcoin/pull/10244#issuecomment-378035305

Travis log here: https://travis-ci.org/bitcoin/bitcoin/jobs/361243719#L2810

Note the JSON exception:

```
test_framework.authproxy.JSONRPCException: The mempool was not loaded yet (-1) 
```

That exception was introduced here: https://github.com/bitcoin/bitcoin/commit/cb1e319fe9e198c9c5cf5236fe9af5a3d748b9e8#diff-a0c8f511d90e83aa9b5857e819ced344R1617

cc @jtimon 
private:
    /**
     * The set of all CBlockIndex entries with BLOCK_VALID_TRANSACTIONS (for itself and all ancestors) and
     * as good as our current tip or better. Entries may be failed, though, and pruning nodes may be
     * missing the data for the block.
     */
    std::set<CBlockIndex*, CBlockIndexWorkComparator> setBlockIndexCandidates;
    /**
     * Every received block is assigned a unique and increasing identifier, so we
     * know which one to give priority in case of a fork.
     */
    CCriticalSection cs_nBlockSequenceId;
    
    int32_t nBlockSequenceId = 1;
    
    int32_t nBlockReverseSequenceId = -1;
    
    arith_uint256 nLastPreciousChainwork = 0;
    /** In order to efficiently track invalidity of headers, we keep the set of
      * blocks which we tried to connect and found to be invalid here (ie which
      * were set to BLOCK_FAILED_VALID since the last restart). We can then
      * walk this set and check if a new header is a descendant of something in
      * this set, preventing us from having to walk mapBlockIndex when we try
      * to connect a bad block and fail.
      *
      * While this is more complicated than marking everything which descends