Forest and Lotus byte fields conformance

[LesnyRumcajs]

Issue summary

For WalletSign, Lotus accepts both base64-encoded, and arrays of bytes in the form of decimal integers as input for byte fields. Forest supports only base64-encoded fields.

Sample JSON accepted by Lotus and not accepted by Forest:

{
    "jsonrpc": "2.0",
    "method": "Filecoin.WalletSign",
    "id": 1,
    "params": [
        "t3ueszxdo5aeq2udr3xyytcqdexj7oke2yozgsjwttfvvxto7adpthaukmubezu6556gisbxqgqgqr6w3p3ave",
        [
            150,
            245,
            251,
            29,
            90,
            2,
            250,
            159,
            103,
            237,
            51,
            146,
            115,
            146,
            195,
            122,
            233,
            39,
            224,
            211,
            33,
            128,
            147,
            132,
            18,
            36,
            108,
            47,
            19,
            189,
            79,
            66
        ]
    ]
}

Open questions:

1. Is this only for this method, or are all byte fields in all endpoints supported with both encodings?
2. How difficult is supporting it with the current RPC framework? Should all tests also try the secondary encoding so that they're more exhaustive?
3. How important is it to RPC consumers to send decimal bytes? Do they formulate it on their own, or is there some tooling already that generates this form by default? In general, it seems wasteful. Base64 is more space-efficient and likely faster to deserialize.

Other information and links