Instead of providing a ready promise, use an async factory function

[lucacasonato]

Currently a Socket instance can be in one of three states:

• connecting: in this case ready and closed are both pending
• connected: in this case ready is resolved, closed is pending
• closed: in this case ready and closed are both resolved

The API design could become a lot more straightforward if instead of providing this ready promise on the class, the constructor of the class itself would provide the functionality of the ready promise. This would also allow us to change stream from being a function that returns a Promise<ReadableStream>, to a simple readable property of type ReadableStream.

This works because a socket is always in the "connected" state initially:

• if the connection fails, an instance of the Socket interface is never created, because the factory function rejects
• if the connection does not fail, that means it connected

[Exposed=Window,Worker]
interface Socket {
  // Note: this interface has no constructor

  // `open` rejects if the connection can not be established. If it succeeds, the connection was successfully established.
  static Promise<Socket> open(SocketOptions options);
 
  // `stream()` gets removed - `readable` replaces it.
  readonly attribute ReadableStream readable;

  // imagine the other properties being here
};

[jasnell]

While I like this approach, the API pattern seems potentially less ergonomic for the server side. Specifically, in the following case: is the socket already in the ready state when the event is emitted?

addEventListener('socket', ({socket}) => {
  // is the socket already ready?
});

If it's not already in the ready state, what does the user do in the very rare cases where it might need to wait for the socket to be in a ready state before performing any actions on it (shouldn't be common at all but still worth considering...

If the socket is already in the ready state, what defines "ready" when we're talking about a TLS connection where the user-code may want to interact with the TLS handshake somehow? For instance, in Node.js' existing api there are ways to hook the client hello, providing an OCSP response, selecting a pre-shared key, etc.