Should WASI attempt to specify any form of resource limits? #890

This issue is borne out of a recent CVE in Wasmtime in addition to two related issues -- #888 and #889. The basic summary is: should WASI document any sort of guarantees for guests with respect to resource consumption?

Previously Wasmtime had a few issues with it orthogonal to any particular WASI API:

• Wasmtime had no limit on the number of Component Model resources that could be created. For example you could infinitely call wasi:clocks/monotonic-clock.subscribe-duration. This would store no resources on the guest side of things but it would force the host to grow the resource table quiet large.
• Wasmtime had no limit on the size of values being copied from the guest to the host. For example by calling wasi:filesystem/types.descriptor#write a guest could force an allocation of arbitrary size to get copied to the host. An extreme case of this is wasi:http/types.fields#from-list where by passing a nested list to the host it's possible for the guest to create a quadratically-sized allocation on the host.

For both of these issues Wasmtime now has hardcoded limits after which a guest will trap, but like with #888 and #889 this is considered a bit of a band-aid than a true fix. The question here is: should WASI specify anything in this regard? Should WASI place a hard limit on the size of buffers transmitted to the host? Should WASI provide some sort of function indicating the maximum number of resources the guest can allocate? (e.g. POSIX ulimit)

WASI could, for example, provide ulimit-style functions to get/set limits. This would serve the purpose of informing the guest as to what the limits currently are and additionally provide the ability to raise the limits if the host allows it. Hosts could then provide much smaller by-default limits which have different hard caps that cannot be increased.

Alternatively WASI could document, individually for all functions with anything list-like, what the maximum size of the list is that's allowed. Hosts would be forced to support up to that amount but guests could expect traps when exceeding this amount.

Overall I'm not sure what the best direction forward is myself, and I'm curious what others think! I feel though this is distinct enough from #888 and #889 to warrant its own issue, but it may also end up with the same resolution for all these issues.