fix: await peer discovery start in libp2p start

[wemeetagain]

_setupPeerDiscovery returns a Promise that resolves after all discovery modules are started.
Because we are not awaiting _setupPeerDiscovery in the call to libp2p.start, we run into a situation where underlying discovery modules have not been started until after the top-level start has resolved.
This can lead to unintended behavior where discovery modules may be started after the libp2p instance has been stopped.

eg:

async function startStopNode() {
  const node = createLibp2pWithDiscoveryModules();
  await node.start();
  // after ^ statement, the libp2p instance has started
  // but the discovery modules haven't, the `d.start()` calls are in a promise that hasn't been executed yet
  await node.stop();
  // after ^ statement, the libp2p instance has stopped
  // and each discovery module has called `d.stop()`
  // however the discovery modules have not actually been started.
  // eventually, the original `d.start()` calls are executed (leading to inconsistent state: libp2p stopped, discovery modules started)
}

This is a minimal fix to await _setupPeerDiscovery in the process of starting a libp2p node. The new behavior now awaits all peer discovery modules being started before resolving that the lib2p node has started.

[vasco-santos]

This looks good!

The CI is failing on a browser test, because we are using mdns in it, which is not supported. As we were not waiting on start, the test is passing before.
@wemeetagain could you change that test to use libp2p-bootstrap instead? You will need to provide some multiaddrs in the config, but it will work the browser test.

[jacobheun]

I'll submit a followup PR to fix the tests since this is technically unrelated and just exposed an exiting issues with them.