rpc: unconstrain meta field for MintAssets

[Roasbeef]

In this commit, we stop trying to strictly parse the meta field. Instead, users can set it to w/e they want, with the default being opaque. This lets users start to add structure to the meta field from day one. One example is a set meta with fields that dictate how the asset unit is to be displayed. This can be used to do things like leverage the current fix point format to add decimal places for display.

[jharveyb]

The underlying proof.MetaReveal.MetaType field is uint8, but the matching field on the RPC request is int32 - we should still clamp it to uint8 before conversion.

[Roasbeef]

but the matching field on the RPC request is int32 - we should still clamp it to uint8 before conversion.

Aren't we effectively doing that just with the cast?

https://go.dev/play/p/sSqSvPQEDi-

[guggero]

Aren't we effectively doing that just with the cast?

Yes, but that would just truncate the value and lead to unexpected behavior. I think what @jharveyb meant was to return an error if the value was bigger than math.MaxUint8.

[guggero]

LGTM pending the mentioned check for value overflow.

[jharveyb]

Aren't we effectively doing that just with the cast?

Yes, but that would just truncate the value and lead to unexpected behavior. I think what @jharveyb meant was to return an error if the value was bigger than math.MaxUint8.

Or negative

[guggero]

Ah, I guess we should at least make it uint32 on the RPC level then.

[jharveyb]

Yeah I could find where it was defined as int32, just that the concrete type is an enum, but I would expect that to be uint32 and not int32 anyways.

Also may want a test to make sure that the same strict meta type handling isn't also present elsewhere in the minting logic.

[guggero]

Right, I forgot it was an enum. Looks like gRPC by default uses int32 even though that doesn't make that much sense. Don't think there's a way to influence that. So just over- and underflow checks should be enough.