Adversarial Arbitrary values for fuzzing

[brson]

What problem does your feature solve?

In #957 I mentioned that the Arbitrary impls for contract types never generate "adversarial" values.

The Soroban type system allows for Vals to have various states that are unexpected but representable. The fuzzing infrastructure doesn't generate these.

What would you like to see?

Vals with bad tags

These are no longer allowed by the runtime.

If a fuzz tests asks for a raw Val type then we should sometimes give them one with a bogus tag.

Vecs and maps with heterogeneous element types

Done.

The Rust wrappers around vecs and maps are not fully recursively typechecked when created - individual element accesses may fail due to dynamic typing errors.
When arbitrary vecs and maps are requested we should occasionally return ones where the keys and/or values are not the expected type but a random type.

Object types with invalid references

These are no longer allowed by the runtime.

For any of the possible object types (the ones that aren't encoded directly in the 64-bit rawval), we should sometimes provide a broken value; a good tag, but a reference that doesn't exist. I believe these are representable within the typed Rust wrappers around the various object kinds, and will produce errors at access-time.

Object types that are shared references

These are not actually possible. Soroban values are immutable.

Any object type might be a shared and mutable reference in the Soroban type system. This is something that would likely be unexpected to Rust programmers.

It would be desirable that, for any object types, the Arbitrary implementation returns the exact same reference as in a previous invocation, creating shared object references within the contract.

This is a pretty tough thing to do because it requires remembering the state of previous Arbitrary invocations. We would need to do this inside our SorobanArbitrary implementations, probably by stashing away previous objects in some private location in Env, then pulling them back out and returning them.

Deeply nested vecs and maps

I don't think this is worth doing. It would be rare code that would be rare code that would actually fail to this type, and the inevitable impact would be stack overflow and transaction failure.

This probably only makes sense for arbitrary Vals - typed vectors and maps can't be arbitrarily-deeply recursive. So deeply-nested containers may not be so useful for finding real bugs - it will only matter if a contract is attempting to fully and recursively interpret Val types, which would be an ambitious thing for a contract to do.

But we could provide deeply nested vecs and maps when a Val is requested.

BytesN with more than N bytes.

I don't think this is worth doing. It's possible to construct unsafely, and probably possible to transmit between contracts, but the constructor from Val to BytesN will always fail and terminate the transaction.

These may be possible.

What alternatives are there?

Don't do any of these.

[brson]

Another unexpected but probably possible case:

BytesN that actually has > N bytes.

[brson]

soroban-env has checks for object validity now that should make it impossible to create invalid objects.

[brson]

soroban-env now also rejects bad tags

[brson]

Done.