Using Bitcoin Core v0.15.1

I have just set `onlynet=onion` in my `bitcoin.conf` file and have the following in my logs after node restart:

    2018-02-03 12:40:52 receive version message: /Satoshi:0.15.1/: version 70015, blocks=507429, us={IPv4}:{port), peer=0
    2018-02-03 12:41:15 receive version message: /Satoshi:0.14.2/: version 70015, blocks=507429, us={IPv4}:{port), peer=2
    2018-02-03 12:41:22 receive version message: /Satoshi:0.14.2/: version 70015, blocks=507429, us={IPv4}:{port), peer=3
    2018-02-03 12:41:28 receive version message: /Satoshi:0.15.0/: version 70015, blocks=507429, us={IPv4}:{port), peer=4
    2018-02-03 12:41:57 receive version message: /Satoshi:0.15.99/: version 70015, blocks=526679, us={IPv4}:{port), peer=5
    ...
    2018-02-03 12:44:11 receive version message: /Satoshi:0.15.1/: version 70015, blocks=507429, us=[::]:0, peer=6

The peer 6 was an onion.

My `bitcoin.conf` file is as follows:

    uacomment={redacted}
    prune=10239
    banscore=10
    bantime=31536000
    maxmempool=900
    mempoolexpiry=2160
    proxy=127.0.0.1:9050
    listen=1
    bind=127.0.0.1
    onlynet=onion

All the `Used for reaching peers via` tick boxes are still ticked but disabled when I look in Options>Newtork.

Bitcoin Core should not initiate IPv4 (or IPv6) connections when `onlynet=onion`.  These connections should not be seed nodes due to low addresses:

    2018-02-03 12:40:30 Loaded 66198 addresses from peers.dat  254ms

I get some IPv4 version messages each time I restart the node.

Note: added both `dns=0` and `dnsseed=0` at the same time and this *seems* to resolve the issue with limited testing. These entries should not be necessary to limit IPv4 outgoing connect.

If people need to setup Tor for testing, the setup I have used is here on [Bitcoin.SE](https://bitcoin.stackexchange.com/a/70070/75001)
argsman.AddArg("-rpcworkqueue=<n>", strprintf("Set the depth of the work queue to service RPC calls (default: %d)", DEFAULT_HTTP_WORKQUEUE), ArgsManager::ALLOW_ANY | ArgsManager::DEBUG_ONLY, OptionsCategory::RPC);
    argsman.AddArg("-server", "Accept command line and JSON-RPC commands", ArgsManager::ALLOW_ANY, OptionsCategory::RPC);
#if HAVE_DECL_FORK
    argsman.AddArg("-daemon", strprintf("Run in the background as a daemon and accept commands (default: %d)", DEFAULT_DAEMON), ArgsManager::ALLOW_ANY, OptionsCategory::OPTIONS);
    argsman.AddArg("-daemonwait", strprintf("Wait for initialization to be finished before exiting. This implies -daemon (default: %d)", DEFAULT_DAEMONWAIT), ArgsManager::ALLOW_ANY, OptionsCategory::OPTIONS);
#else
    hidden_args.emplace_back("-daemon");
    hidden_args.emplace_back("-daemonwait");
#endif
#if defined(USE_SYSCALL_SANDBOX)
    argsman.AddArg("-sandbox=<mode>", "Use the experimental syscall sandbox in the specified mode (-sandbox=log-and-abort or -sandbox=abort). Allow only expected syscalls to be used by bitcoind. Note that this is an experimental new feature that may cause bitcoind to exit or crash unexpectedly: use with caution. In the \"log-and-abort\" mode the invocation of an unexpected syscall results in a debug handler being invoked which will log the incident and terminate the program (without executing the unexpected syscall). In the \"abort\" mode the invocation of an unexpected syscall results in the entire process being killed immediately by the kernel without executing the unexpected syscall.", ArgsManager::ALLOW_ANY, OptionsCategory::OPTIONS);
#endif 
    
    argsman.AddHiddenArgs(hidden_args);
}
static bool fHaveGenesis = false;
static GlobalMutex g_genesis_wait_mutex;
static std::condition_variable g_genesis_wait_cv;
static void BlockNotifyGenesisWait(const CBlockIndex* pBlockIndex)
{
    if (pBlockIndex != nullptr) {
        {
            LOCK(g_genesis_wait_mutex);
            fHaveGenesis = true;
        }
        g_genesis_wait_cv.notify_all();
    }
}
#if HAVE_SYSTEM
static void StartupNotify(const ArgsManager& args)