Guests should not be able to force hosts to allocate arbitrary random bytes

Currently the wasi:random/random.get-random-bytes function takes a u64 argument and is documented as returning a list of that length. This is a possible resource exhaustion vector where a guest could force a host to allocate a very large amount of memory. There's some more details at https://github.com/advisories/GHSA-852m-cvvp-9p4w which affected Wasmtime recently.

In wasmtime as a "quick fix" we've placed a hard limit on get-random-bytes where the guest will trap if it asks for more than that value, but this is seen as a band-aid. Ideally the interface itself would gracefully handle this one way or another. Some possibilities for example are:

• Add a second function which is "what's the maximum size that can be asked for?". This would permit guests to understand how large the host can go and handle differences across hosts. Additionally hosts could then trap guests that ask for too many bytes.
• Change get-random-bytes to return a result where the only possible error is "you asked for too many". This avoids the need to trap the guest and enables guests to back off to, for example, half the size or some other chunking strategy.

In theory it would also be nice to be able to document "hosts should service requests for at least this many bytes without errors or trap" so guests know what the guarantees are, but that might be a step too far.

For WASIp2 I understand that changing the signature is off the table, but we could in theory do so for WASIp3 in the time we have remaining.

Start with the WASI random/random.get-random-bytes interface and review the linked resource-exhaustion advisory and Wasmtime's quick-fix behavior. Compare the proposed maximum-size and result-based approaches, considering the stated WASI Preview 2 and Preview 3 constraints; done means an agreed interface direction and documented host/guest behavior.