### Describe the issue

Restarting bitcoin, mempool starts filling from scratch.

### Can you reliably reproduce the issue?
#### If so, please list the steps to reproduce below:
1. Wait for mempool to reach for example 3000 transactions
2. Restart bitcoin
3. Watch mempool filling slowly from scratch

### Expected behaviour
Mempool would already contain ~3000 TX on startup

### Actual behaviour
It starts at 0 and fills up slowly with a few per second.

### Screenshots.
http://imgur.com/a/or82d

### What version of bitcoin-core are you using?
Windows x64 0.14rc1 binary from https://bitcoin.org/bin/bitcoin-core-0.14.0/test.rc1/


### Any extra information that might be useful in the debugging process.
I may not be aware of how the mempool.dat thing works and there could just be a misunderstanding.

UpdateTip(pindexDelete->pprev, chainparams);
    
    
    for (const auto& tx : block.vtx) {
        GetMainSignals().SyncTransaction(*tx, pindexDelete->pprev, CMainSignals::SYNC_TRANSACTION_NOT_IN_BLOCK);
    }
    return true;
}
static int64_t nTimeReadFromDisk = 0;
static int64_t nTimeConnectTotal = 0;
static int64_t nTimeFlush = 0;
static int64_t nTimeChainState = 0;
static int64_t nTimePostConnect = 0;
/**
 * Used to track blocks whose transactions were applied to the UTXO state as a
 * part of a single ActivateBestChainStep call.
 */
struct ConnectTrace {
    std::vector<std::pair<CBlockIndex*, std::shared_ptr<const CBlock> > > blocksConnected;
};
/**
 * Connect a new block to chainActive. pblock is either NULL or a pointer to a CBlock
 * corresponding to pindexNew, to bypass loading it again from disk.
 *
 * The block is always added to connectTrace (either after loading from disk or by copying
 * pblock) - if that is not intended, care must be taken to remove the last entry in
 * blocksConnected in case of failure.
 */
bool static ConnectTip(CValidationState& state, const CChainParams& chainparams, CBlockIndex* pindexNew, const std::shared_ptr<const CBlock>& pblock, ConnectTrace& connectTrace)