RPC: Decouple message creation from message encoding/decoding

[nb-ohad]

Explain the changes

1. Create a new RpcMessage class to represent a generic non-encoded RPC message that can describe any op (in contrast to RpcReqeust that can be used solely for requests and responses).
2. Move encoding/decoding responsibilities (from and to transit representation) into rpc_connection where the base class just delegate to the old encode/decode code inside RpcRequest.
3. Decode on "message" and emit a "decoded_message" event with the decoded RpcMessage.
4. Override the encoding and decoding for fcall connections to passthrough the RpcMessage without encoding or decoding.

Issues: Fixed #xxx / Gap #xxx

Testing Instructions:

[guymguym]

Looks good, did you check the CI failures?

[guymguym]

@nimrod-becker I'm not sure what happened to TravisCI but I cant find how to restart thee build.
@nb-ohad perhaps you can simply rebase and push to rebuild?

[nb-ohad]

@guymguym I restarted the build

[guymguym]

@nb-ohad It failed. Not clear if related so I restarted the tests now.

[nb-ohad]

It seems that not serializing the payload (body) into a buffer (and then deserializing) creates a difference with regard to encoding.

I am working on trying to pinpoint the problem.
I will update here

[guymguym]

any news on that?

[nb-ohad]

@guymguym ping on review for the second commit

[guymguym]

@nb-ohad One last comment about making the omit conditional to avoid copying the params/reply objects, the copy is shallow but still this is very much unneeded.
Other than that it looks good to me.

[guymguym]

@nb-ohad To summarize this PR - it tries to improve how rpc_fcall (which is an optimized rpc path for calls which are executed in the same process) by getting rid of the intermediate large memory allocations created by JSON.parse(JSON.stringify(..)) and instead use cloneDeep. It does introduce some subtleties of cloning in rpc_fcall, but the rest of the system is not affected.

However, how do you measure the effect of this change? Did it help? is it possible that it is somehow slower/heavier than previous solution? Of course - I don't really think so. But we need to work with some numbers here.

I would suggest to enhance rpc_benckmark.js for that. You can add a new --fcall flag that will do the benchmark inside one process (both client and server). And then our main metric is operations/second and the higher the better, or something more complicated is needed to see the effect? We can run it with node --trace-gc for GC info. And we can add anything else we need to that benchmark to simulate the effect on a real process...

[nb-ohad]

@guymguym This optimization is not about getting rid of JSON.parse/JSON.stringify because deepClone will also create a new object tree. It is about removing the need in the allocation of buffers for interprocess calls (header and body buffers)

regarding measurements, This is a thing that is very hard to measure and the normal rpc_banchmark will not yield any meaningful results. We initiated this task as a result of the measurement that we did with a high volume, small object tests
The results indicated that a lot of memory pressure was produced in this kind of scenario coming from 3-4 prime locations in the code, one of them was the allocation of buffers and cloning the message body object Tree.

We decided to tackle the points according to their impact and ease of fixing. So we choose to improve memory allocations in the instantiation of our API clients (#6022) and minimizing allocations for RPC calls via 'fcall' connections

[nb-ohad]

@guymguym as of your request for enhancements to rpc_benckmark:
#6173