Remove rejection of large JSON-RPC requests

[tomaka]

cc #1098

After thinking about it, I've decided to go ahead and remove the limit of 64 MiB for JSON-RPC requests.

The presence of a limit is bad by itself due to the "additional thing to think about".

The existence of this limit was meant to limit the capacity for JSON-RPC clients to DoS the server by sending large requests. After all, the server can only allocate 4 GiB of memory in total due to compiling for wasm32.
However, the current limit at 64 MiB is too large to be efficient. A client can simply send as many 64 MiB requests as possible and will reach the memory cap nonetheless.
Reducing the limit runs of the risk of actually running accidentally into said limit with legitimate requests.

If the JSON-RPC client is trusted, then there's nothing to do as the JSON-RPC client isn't going to DoS the server. There's still a risk of running out of memory space, but it will be solved by #88, and to me returning an error if requests are too large is no better than crashing.

If the JSON-RPC client isn't trusted, then it's good to have a limit to the size of requests (even with #88). When writing this PR, I initially added an option to addChain that allows specifying a limit. However, the code that wraps around smoldot also needs to enforce a limit for itself anyway, and as such a smoldot-specific solution isn't a good idea.

[tomaka]

Note that this is related but orthogonal to #85.

#85 would back-pressure the client until the total size of queued requests is below a certain threshold.