Test-runtime: Run Substrate node on port 0 for more reliable execution

[jsdw]

We've ran into issues a couple of times now (eg #908) where a nightly build fails because it tried to connect to a Substrate node 6 times without success.

The way that we start said Substrate node up is by selecting a port to use like so:

fn next_open_port() -> Option<u16> {
    match TcpListener::bind(("127.0.0.1", 0)) {
        Ok(listener) => {
            if let Ok(address) = listener.local_addr() {
                Some(address.port())
            } else {
                None
            }
        }
        Err(_) => None,
    }
}

And then telling Substrate to start using that port.

I wonder whether the port isn't freed up quickly enough sometimes, and so Substrate picks another random port to start on or something like that, leading to an inability to connect to it?

In any case, in our tests we take a different approach; we start Substrate with a --ws-port=0, and then parse the stdout until we find the actual port that it picked. This may be a more reliable approach to take, since we'll always try connecting on the actual port that it used, and won't run the issue of providing a port that ends up being in use. So, let's update our build code to do the same thing.

[niklasad1]

It's probably a good idea but just a reminder I have opened paritytech/substrate#13384 which will break things :P

[jsdw]

It's probably a good idea but just a reminder I have opened paritytech/substrate#13384 which will break things :P

Ooh noted, thanks! I guess the stdout logs will be the same so it should be a trivial change to fix the commandline opt change from --ws-port to --rpc-port where needed! There will be some breaking though since we can't support both old and newer Substrate binaries at the same time I think