One of my nodes using `onlynet=tor` nodes is completely broken with current master as of 97a35f3ae5bff7f4a25d37d8961191fdbc8c5b67.

Tor is manually configured. Relevant `bitcoin.conf`:
```
onlynet=onion
proxy=127.0.0.1:9050
onion=127.0.0.1:9050
```

It does not manage to make any outgoing connections. The log has an endless stream of:
```
2021-03-03T13:42:13Z Socks5() connect to […].onion:8333 failed: general failure
2021-03-03T13:42:13Z Socks5() connect to […].onion:8333 failed: general failure
2021-03-03T13:42:14Z Socks5() connect to […].onion:8333 failed: general failure
2021-03-03T13:42:14Z Socks5() connect to […].onion:8333 failed: general failure
2021-03-03T13:42:15Z Socks5() connect to […].onion:8333 failed: general failure
2021-03-03T13:42:15Z Socks5() connect to […].onion:8333 failed: general failure
2021-03-03T13:42:16Z Socks5() connect to […].onion:8333 failed: general failure
2021-03-03T13:42:16Z Socks5() connect to […].onion:8333 failed: general failure
2021-03-03T13:42:17Z Socks5() connect to […].onion:8333 failed: general failure
2021-03-03T13:42:17Z Socks5() connect to […].onion:8333 failed: general failure
2021-03-03T13:42:18Z Socks5() connect to […].onion:8333 failed: general failure
2021-03-03T13:42:18Z Socks5() connect to […].onion:8333 failed: general failure
2021-03-03T13:42:19Z Socks5() connect to […].onion:8333 failed: general failure
2021-03-03T13:42:19Z Socks5() connect to […].onion:8333 failed: general failure
2021-03-03T13:42:20Z Socks5() connect to […].onion:8333 failed: general failure
2021-03-03T13:42:20Z Socks5() connect to […].onion:8333 failed: general failure
…
```
(multiple messages per second, all `[…]` are short v2 onion addresses)

```
$ systemctl status tor
● tor.service - Anonymizing overlay network for TCP
     Loaded: loaded (/etc/systemd/system/tor.service; enabled; vendor preset: enabled)
     Active: active (running) since Wed 2021-03-03 14:45:24 CET; 3min 0s ago
    Process: 158931 ExecStartPre=/opt/tor/bin/tor -f /opt/tor/etc/tor/torrc --verify-config (code=exited, status=0/SUCCESS)
   Main PID: 158962 (tor)
      Tasks: 1 (limit: 9367)
     Memory: 38.4M
     CGroup: /system.slice/tor.service
             └─158962 /opt/tor/bin/tor -f /opt/tor/etc/tor/torrc

Mar 03 14:48:20 tor[158962]: Mar 03 14:48:20.000 [warn] Invalid hostname [scrubbed]; rejecting
Mar 03 14:48:20 tor[158962]: Mar 03 14:48:20.000 [warn] Invalid hostname [scrubbed]; rejecting
Mar 03 14:48:21 tor[158962]: Mar 03 14:48:21.000 [warn] Invalid hostname [scrubbed]; rejecting
Mar 03 14:48:21 tor[158962]: Mar 03 14:48:21.000 [warn] Invalid hostname [scrubbed]; rejecting
Mar 03 14:48:22 tor[158962]: Mar 03 14:48:22.000 [warn] Invalid hostname [scrubbed]; rejecting
Mar 03 14:48:22 tor[158962]: Mar 03 14:48:22.000 [warn] Invalid hostname [scrubbed]; rejecting
Mar 03 14:48:23 tor[158962]: Mar 03 14:48:23.000 [warn] Invalid hostname [scrubbed]; rejecting
Mar 03 14:48:23 tor[158962]: Mar 03 14:48:23.000 [warn] Invalid hostname [scrubbed]; rejecting
Mar 03 14:48:24 tor[158962]: Mar 03 14:48:24.000 [warn] Invalid hostname [scrubbed]; rejecting
Mar 03 14:48:24 tor[158962]: Mar 03 14:48:24.000 [warn] Invalid hostname [scrubbed]; rejecting
```

I'll try to see if I can figure out what it's sending. Tor (current master) is otherwise successfully able to connect to hidden services, at least v3 ones.

Did Tor completely remove v2 support?

```
$ /opt/tor/bin/tor --version
Tor version 0.4.6.0-alpha-dev (git-8020ae02abb105db).
Tor is running on Linux with Libevent 2.1.11-stable, OpenSSL 1.1.1f, Zlib 1.2.11, Liblzma 5.2.4, Libzstd N/A and Glibc 2.31 as libc.
Tor compiled with GCC version 9.3.0
```
* here are security critical, since they dictate which UTXO snapshots are recognized
 * as valid.
 */
struct AssumeutxoData {
    
    const uint256 hash_serialized;
    
    
    
    
    const unsigned int nChainTx;
};
std::ostream& operator<<(std::ostream& o, const AssumeutxoData& aud);
using MapAssumeutxo = std::map<int, const AssumeutxoData>;
/**
 * Holds various statistics on transactions within a chain. Used to estimate
 * verification progress during chain sync.
 *
 * See also: CChainParams::TxData, GuessVerificationProgress.
 */
struct ChainTxData {
    int64_t nTime;    
    int64_t nTxCount; 
    double dTxRate;   
};
/**
 * CChainParams defines various tweakable parameters of a given instance of the
 * Bitcoin system.
 */
class CChainParams