FRC46: MintReturn etc. should use Option<IpldBlock> for optional data

[arajasek]

Also:

• MintIntermediate
• TransferReturn
• TransferIntermediate
• TransferFromReturn
• TransferFromIntermediate
• others?

[anorth]

I don't agree with this.

Firstly, this is an FRC spec issue. The RecipientData is currently missing from the FRC and I have a note to add it. But the type will be set there and so we're setting a standard for all tokens. (Edit: ok, the mint method isn't actually standard, but in this case we know that bytes are more appropriate representation for the actual data).

This return data will frequently be very small. The actual use case today is to return an integer. The cost of wrapping that in a block, hashing, writing to block store, reading, deserializing etc is a huge overhead for such a simple thing.

This looks like one of the first practical cases where we are running into block visibility in practise. For a large return object, one might want to return a CID as a capability to read a block (and the VM will need to confirm the CID corresponds to a reachable block, etc, etc). I expect actors in general will be able to do this, but we have a design challenge when designing standards that don't yet know what the data is to be returned. I feel pretty ok about leaving token transfer returns as small inline values. A union type that could also carry a CID (or block handle or whatever) could also be ok, but needs some design work at the VM level.

[anorth]

cc @Stebalien