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
```
#endif
#ifdef USE_POLL
#include <poll.h>
#endif
#include <algorithm>
#include <cstdint>
#include <functional>
#include <optional>
#include <unordered_map>
#include <math.h>
static constexpr size_t MAX_BLOCK_RELAY_ONLY_ANCHORS = 2;
static_assert (MAX_BLOCK_RELAY_ONLY_ANCHORS <= static_cast<size_t>(MAX_BLOCK_RELAY_ONLY_CONNECTIONS), "MAX_BLOCK_RELAY_ONLY_ANCHORS must not exceed MAX_BLOCK_RELAY_ONLY_CONNECTIONS.");
const char* const ANCHORS_DATABASE_FILENAME = "anchors.dat";
static constexpr std::chrono::minutes DUMP_PEERS_INTERVAL{15};
static constexpr int DNSSEEDS_TO_QUERY_AT_ONCE = 3;
/** How long to delay before querying DNS seeds
 *
 * If we have more than THRESHOLD entries in addrman, then it's likely
 * that we got those addresses from having previously connected to the P2P
 * network, and that we'll be able to successfully reconnect to the P2P
 * network via contacting one of them. So if that's the case, spend a
 * little longer trying to connect to known peers before querying the
 * DNS seeds.
 */
static constexpr std::chrono::seconds DNSSEEDS_DELAY_FEW_PEERS{11};
static constexpr std::chrono::minutes DNSSEEDS_DELAY_MANY_PEERS{5};
static constexpr int DNSSEEDS_DELAY_PEER_THRESHOLD = 1000; 
static constexpr std::chrono::seconds MAX_UPLOAD_TIMEFRAME{60 * 60 * 24};
#define FEELER_SLEEP_WINDOW 1
enum BindFlags {