Deprecate implicit types and define explicit message types for JSON format

[peplin]

For sending from a VI to a client, the implicit types are those were we have to infer whether it is a translated message, CAN message, diagnostic message, etc. For example, these are two different implicit messages:

{"name": "foo, "value": bar"}
{"id": 42, "bus": 1, "data": "0x1234"}

The first is a simple, translated message. The second is a CAN message. The only way for the client to tell the different is to check in a particular order if the message contains the fields required for each message type.

The pros of implicit messages is that they are very concise - no extra type field to send over Bluetooth/USB. Up until now, they have also been trivial to process - we just didn't have that much variation in message types.

The cons, which is why I've opened this ticket: as we expand to many more types of message (diagnostic requests and responses, commands, etc), this is getting very cumbersome. It's also tricky if one message is a superset of another. You have to make sure to check the message with more required fields first, otherwise you risk misidentification.

For the previous example messages, we would wrap the object with another key that tells the exact type, e.g.:

{"simple": {"name": "foo, "value": bar"}}
{"can": {"id": 42, "bus": 1, "data": "0x1234"}}

It's now much easier for the client to deserialize the messages. The types as of today would be:

• simple
• evented
• can
• diagnostic
• command

The cons? Each message has a few extra bytes to include the explicit type. However, now that we have the binary message format (with protocol buffers), anyone that needs the utmost level of performance should be using that instead (which are already all explicitly typed).

To summarize: If you need performance, use the binary message format. If you need flexibility, readability or easier deserialization, use JSON. Once implemented, we can start to deprecate the implicit JSON format over a couple over firmware releases.