### 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.

int nLastBlockFile = 0;
    /** Global flag to indicate we should check to see if there are
     *  block/undo files that should be deleted.  Set on startup
     *  or if we allocate more file space when we're in prune mode
     */
    bool fCheckForPruning = false;
    /**
     * 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;
    
    std::set<CBlockIndex*> setDirtyBlockIndex;
    
    std::set<int> setDirtyFileInfo;
} 
/* Use this class to start tracking transactions that are removed from the
 * mempool and pass all those transactions through SyncTransaction when the
 * object goes out of scope. This is currently only used to call SyncTransaction
 * on conflicts removed from the mempool during block connection.  Applied in
 * ActivateBestChain around ActivateBestStep which in turn calls:
 * ConnectTip->removeForBlock->removeConflicts
 */
class MemPoolConflictRemovalTracker