Ensure remote-address is allowed when creating UDP stream

[rylev]

Until now, the remote-address argument to wasi:sockets/udp-socket#stream was not checked against the Pool of allowed IP addresses. Now, we store the Pool from network into the socket object in wasi:sockets/udp-socket#bind and later use that Pool in wasi:sockets/udp-socket#stream to check that remote-address is allowed.

The check itself is a bit hacky since Pool doesn't seem to expose a way to just check an address so we use PoolExt to create a UdpConnecter which we will fail if we don't have permission to connect to the remote address.

I can add a test once I figure out the testing story in #7647

[rylev]

I've addressed the PR feedback:

• Pool is now wrapped in an Arc to make cloning cheaper.
• HostOutgoingDatagramStream will check the provided addr against the Pool before sending a datagram.

@alexcrichton I'm not sure what the testing story should look like here. I don't see where the wasi implementations are being tested against non-default WasiCtxs. I believe all tests are running with full network. I suppose whatever solution we decide on here should also work for #7647 as well.

[alexcrichton]

I wrote up some thoughts here for how this might be tested (in case anyone lands on this PR in the future)

[alexcrichton]

Could this start as None to represent that it's bound-late? That could also help overwriting it by accident by only writing to it if it's None

[alexcrichton]

(same below too)

[rylev]

Pushed a change that does this, but I have a question about the exact desired semantics of start-bind. Take the following_example:

// `bad_addr` is an address that is not permitted
assert!(sock.start_bind(bad_addr).is_err());
// `good_addr` is permitted
sock.start_bind(good_addr);

As currently written the second call to start-bind will fail with InvalidState since the pool has already been set on the socket. Is this right? Previously, this would have succeeded. I would imagine that start_bind should be allowed to be called multiple times as long as the socket has not successfully been bound before.

[rylev]

I removed the check that the pool was not previously set as this broke some tests. Once we decide on what the semantics should be, I can adjust.

[alexcrichton]

cc @badeend on this you are probably best-equipped to answer this

[badeend]

@rylev

From the API's perspective, unbound sockets (Default) never need a pool, and all other states (BindStarted, Bound, Connected) could've only be reached by calling bind at some point, so they always have access to a pool. A way to codify this could be:

pub(crate) enum UdpState {
    Default,
    BindStarted(Arc<Pool>),
    Bound(Arc<Pool>),
    Connected(Arc<Pool>),
}

Also, OutgoingDatagramStream's pool field doesn't have to be optional, because you can never call stream on an unbound socket.

---

As currently written the second call to start-bind will fail with InvalidState since the pool has already been set on the socket. Is this right?

From the caller's perspective, the start-bind call should preferably succeed or fail atomically. Using the enum layout above would automagically fix that.

[alexcrichton]

I'm gonna go ahead and queue this for merge, and @rylev says they're happy to follow-up on semantic changes in a follow-up.