wasi:random: Allow get(-insecure)-random-bytes to return fewer bytes than requested

[badeend]

Different design to reach the same goal as: #895

[ricochet]

LGTM cc @sunfishcode @pchickey @alexcrichton

[badeend]

@pchickey In the previous PR you mentioned:

I think we should change the docs of both p2 and p3 to permit implementations to return less than requested.

The P2 interface doesn't explicitly document any relationship between the input parameter and the returned list. Though, suddenly returning less data is strictly speaking a breaking change.

I've only touched the P3 interface in this PR. Let me know whether it's acceptable to change the P2 intrface too.

[alexcrichton]

My interpretation of wasip2's documentation:

Return len cryptographically-secure random or pseudo-random bytes.

is that by the letter-of-the-law it would be a breaking change to update wasip2's behavior. That being said if it's not like WASIp2 is the most widely deployed platform in the world where changing anything breaks someone, so practically it might be possible to actually implement such a change.

One data point here is that wasi-libc's implementation exits upon receiving too-few bytes. That'll need to change for WASIp3, in which case it's probably pretty easy to do the same for wasip2 as well.

Overall, r+ from me for wasip3, and personally I'd consider changing wasip2 on the table but I wouldn't want to block wasip3.

Another possible hammer to deploy for wasip2 is to deprecate the existing functions in favor of new ones with these new semantics.

[badeend]

wasi-libc's implementation exits upon receiving too-few bytes

Hmm, so even with a sample size=1, we've already found a implementation that will break when returning fewer bytes.
We have pretty direct control over wasi-libc, so it wouldn't be the end of the world.
But let's keep this PR scoped to 0.3 for now, agreed?