### 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
   CService resolvedAddress;
    bool fConnected;
    bool fInbound;
};
class CNodeStats;
class CClientUIInterface;
struct CSerializedNetMsg
{
    CSerializedNetMsg() = default;
    CSerializedNetMsg(CSerializedNetMsg&&) = default;
    CSerializedNetMsg& operator=(CSerializedNetMsg&&) = default;
    
    CSerializedNetMsg(const CSerializedNetMsg& msg) = delete;
    CSerializedNetMsg& operator=(const CSerializedNetMsg&) = delete;
    std::vector<unsigned char> data;
    std::string m_type;
};
/** Different types of connections to a peer. This enum encapsulates the
 * information we have available at the time of opening or accepting the
 * connection. Aside from INBOUND, all types are initiated by us.
 *
 * If adding or removing types, please update CONNECTION_TYPE_DOC in
 * src/rpc/net.cpp and src/qt/rpcconsole.cpp, as well as the descriptions in
 * src/qt/guiutil.cpp and src/bitcoin-cli.cpp::NetinfoRequestHandler. */
enum class ConnectionType {
    /**
     * Inbound connections are those initiated by a peer. This is the only
     * property we know at the time of connection, until P2P messages are
     * exchanged.
     */
    INBOUND,
    /**
     * These are the default connections that we use to connect with the
     * network. There is no restriction on what is relayed; by default we relay
     * blocks, addresses & transactions. We automatically attempt to open
     * MAX_OUTBOUND_FULL_RELAY_CONNECTIONS using addresses from our AddrMan.
     */
    OUTBOUND_FULL_RELAY,
    /**
     * We open manual connections to addresses that users explicitly requested
     * via the addnode RPC or the -addnode/-connect configuration options. Even if a
     * manual connection is misbehaving, we do not automatically disconnect or
     * add it to our discouragement filter.
     */
    MANUAL,
    /**
     * Feeler connections are short-lived connections made to check that a node
     * is alive. They can be useful for:
     * - test-before-evict: if one of the peers is consi