Replace command name with byte code in p2p message

[kostyantyn]

Is your feature request related to a problem? Please describe This is the header of any p2p message:

//  (4) message start
//  (12) command
//  (4) size
//  (4) checksum

We waste 12 bytes to have a human-readable command name in the binary protocol. Replacing it with the byte-code will allow us to save data transfer. These few bytes sounds like not a lot but let's say receiving 1K tx/sec will be 12Kb/sec extra and it's only for transactions.

Describe the solution you'd like I propose to use uint16 as a byte code for the command name. It gives us 65 536 possible command names. This should be more than enough for the entire lifetime of the chain.

Alternatively, we could go with the varint, but these are the reasons I don't like it:

1. we lose fix-sized header
2. it's only beneficial up to 253. After we would need 3 bytes to encode numbers between 253-65 535 so we can potentially very quickly lose the benefit of it over uint16. And it's hard to imagine that we would need to have a code beyond the 65 535.

[AM5800]

I would add that those human-readable command names are too short sometimes. For example grapheneblock is 13 characters and I had to improvise...

[castarco]

Alternatively, we could go with the varint, but these are the reasons I don't like it:

• we lose fix-sized header
• it's only beneficial up to 253. After we would need 3 bytes to encode numbers between 253-65 535 so we can potentially very quickly lose the benefit of it over uint16. And it's hard to imagine that we would need to have a code beyond the 65 535.

There are other ways to encode variable length integers, we could use the first byte to encode just up to 127 values, and two bytes to encode up to 32767 values, so there's no need to go up to 3 bytes.

On the other hand, if we do that, we can use what we know about p2p commands frequency to give the smaller codes to the more frequent ones.