### FEATURE REQUEST

Currently, when a bitcoin node is set up with a connection to both TOR and normal IPv4/6 internet, the 8 outbound-only connection slots, almost always get filled with nodes connecting over IP.
Adding a config option, which would try to ballance these connections based on what kind of network they go through, would be benefficial in many ways:

1. It would add edges between bitcoin network on TOR and normal internet, reducing delays, and the risks associated with an attacker isolating a part of TOR-bitcoin-network from the rest of the world
(Or an ISP/government man-in-the-middling all the normal IP connections)

2. It would help hide/annonymise normal user's transactions from his/her ISP, by mixing them with TOR-outbound ones

3. It would reduce the stress on normal general purpose TOR exit nodes, as users would more likely/reliably connect to TOR-IPv4/6 bitcoin nodes instead of exiting into normal internet first, and then connecting to default IPv4/6-only bitcoin nodes

I understand it is possible to create such bridges already, by forcing connections to TOR-only nodes, or by just running a node with lots of inbound slots, but I think the proposed option, would greatly increase the number of such relays, and remove the need for user to maintain a TOR-node whitelist, by handing this work off to normal bitcoind connection finding algorithm.

This could be implemented as a minimum number of connections for each network, or just a simple evening boolean switch. (Which could be enabled by default for bitcoind installs with TOR connectivity)

In the future, if bitcoin was to support a new network type (for example cjdns/I2P/GNUnet), this option would help establish a presence on the new network faster

bitcoind: 0.15
dered for eviction from
     *   our AddrMan because another peer is mapped to the same slot in the tried table,
     *   evict only if this longer-known peer is offline.
     * - move node addresses from New to Tried table, so that we have more
     *   connectable addresses in our AddrMan.
     * Note that in the literature ("Eclipse Attacks on Bitcoin’s Peer-to-Peer Network")
     * only the latter feature is referred to as "feeler connections",
     * although in our codebase feeler connections encompass test-before-evict as well.
     * We make these connections approximately every FEELER_INTERVAL:
     * first we resolve previously found collisions if they exist (test-before-evict),
     * otherwise we connect to a node from the new table.
     */
    FEELER,
    /**
     * We use block-relay-only connections to help prevent against partition
     * attacks. By not relaying transactions or addresses, these connections
     * are harder to detect by a third party, thus helping obfuscate the
     * network topology. We automatically attempt to open
     * MAX_BLOCK_RELAY_ONLY_ANCHORS using addresses from our anchors.dat. Then
     * addresses from our AddrMan if MAX_BLOCK_RELAY_ONLY_CONNECTIONS
     * isn't reached yet.
     */
    BLOCK_RELAY,
    /**
     * AddrFetch connections are short lived connections used to solicit
     * addresses from peers. These are initiated to addresses submitted via the
     * -seednode command line argument, or under certain conditions when the
     * AddrMan is empty.
     */
    ADDR_FETCH,
};
/** Convert ConnectionType enum to a string value */
std::string ConnectionTypeAsString(ConnectionType conn_type);
void Discover();
uint16_t GetListenPort();
enum
{
    LOCAL_NONE,   // 
    LOCAL_IF,     // 
    LOCAL_BIND,   // 
    LOCAL_MAPPED, // 
    LOCAL_MANUAL, // 
    LOCAL_MAX
};
bool IsPeerAddrLocalGood(CNode *pnode);
/** Returns a local address that we should advertise to this peer */
std::optional<CAddress> GetLocalAddrForP