### Describe the issue
Because transaction malleability isn't that much of an issue lately, we've decided to let the wallet spend zero conf change. It has happened that we create a transaction just moments before a significant increase in (higher paying) transactions. Because of #9645, there is a chance that you end up with an unconfirmed chain of 24 child transactions. If you let the wallet produce a 25th child, it will return an error because the mempool won't accept it.  This is also problematic in the case we would like to cpfp the whole chain, because other nodes won't relay the transaction to the miners.

### Can you reliably reproduce the issue?
#### If so, please list the steps to reproduce below:
1. Predict an increase in transactions. (You need a crystal ball)
2. Create transaction
3. Create more transactions
4. ?
5. Profit

### Expected behaviour
Ideally it would stop if the chain is 24 transactions long, so one could try a cpfp transaction to compensate for the fees.

### Actual behaviour
It will create a transaction chain of 25 transaction, making it hard to have the whole chain confirmed in a certain time.

### What version of bitcoin-core are you using?
Official binary: 0.13.1
void AddToSpends(const uint256& wtxid, WalletBatch* batch = nullptr) EXCLUSIVE_LOCKS_REQUIRED(cs_wallet);
    /**
     * Add a transaction to the wallet, or update it.  confirm.block_* should
     * be set when the transaction was known to be included in a block.  When
     * block_hash.IsNull(), then wallet state is not updated in AddToWallet, but
     * notifications happen and cached balances are marked dirty.
     *
     * If fUpdate is true, existing transactions will be updated.
     * TODO: One exception to this is that the abandoned state is cleared under the
     * assumption that any further notification of a transaction that was considered
     * abandoned is an indication that it is not safe to be considered abandoned.
     * Abandoned state should probably be more carefully tracked via different
     * chain notifications or by checking mempool presence when necessary.
     *
     * Should be called with rescanning_old_block set to true, if the transaction is
     * not discovered in real time, but during a rescan of old blocks.
     */
    bool AddToWalletIfInvolvingMe(const CTransactionRef& tx, const SyncTxState& state, bool fUpdate, bool rescanning_old_block) EXCLUSIVE_LOCKS_REQUIRED(cs_wallet);
    
    void MarkConflicted(const uint256& hashBlock, int conflicting_height, const uint256& hashTx);
    
    void MarkInputsDirty(const CTransactionRef& tx) EXCLUSIVE_LOCKS_REQUIRED(cs_wallet);
    void SyncMetaData(std::pair<TxSpends::iterator, TxSpends::iterator>) EXCLUSIVE_LOCKS_REQUIRED(cs_wallet);
    void SyncTransaction(const CTransactionRef& tx, const SyncTxState& state, bool update_tx = true, bool rescanning_old_block = false) EXCLUSIVE_LOCKS_REQUIRED(cs_wallet);
    
    std::atomic<uint64_t> m_wallet_flags{0};
    bool SetAddressBookWithDB(WalletBatch& batch, const CTxDestination& address, const std::string& strName, const std::string& strPurpose);
    
    void UnsetWalletFlagWithDB(WalletBatch& batch, uint64_t flag);