Reported by @roasbeef and @chjj on IRC.

### Describe the issue

When we receive a transaction with an unknown input, since 0.13.0 we send a getdata for that transaction in response, to quickly learn the dependency. Unfortunately, we always ask for it as MSG_TX instead of MSG_WITNESS_TX.

### Can you reliably reproduce the issue?

```
18:20:33 < roasbeef> hmm, chjj and I seem to be encountering some odd behavior with segwit enabled core nodes on testnet: they aren't including witness_tx inv's in their getdata's when
                     fetching transactions, so they fetch witness output spending transactions without the witness data (though the service bit is set). this should cause an immediate
                     rejecvt due to the clean-stack rules, but they keep accepting the txns, sending a delayed reject minutes afterwards
18:26:52 < sipa> roasbeef: they send MSG_TX getdatas instead of MSG_WITNESS_TX ?
18:27:11 < roasbeef> sipa: yeh
```

### Expected behaviour

Don't see any MSG_TX getdatas between witness-enabled peers.

### Actual behaviour

See some MSG_TX getdatas.

### What version of bitcoin-core are you using?

```
18:28:08 < chjj> sipa: seems to be both 13.0 and 13.1 nodes
```

/**
     * Sources of received blocks, saved to be able to send them reject
     * messages or ban them when processing happens afterwards. Protected by
     * cs_main.
     * Set mapBlockSource[hash].second to false if the node should not be
     * punished if the block is invalid.
     */
    map<uint256, std::pair<NodeId, bool>> 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;