Restructure IPC ram items

[mrquincle]

Currently it is difficult to bump the protocol version of IPC ram items. This became apparent when fixing https://github.com/crownstone/bluenet/issues/180.

See https://github.com/crownstone/bluenet/blob/master/source/shared/ipc/cs_IpcRamData.h

The protocol version is the very first field in bluenet_ipc_bootloader_data_t, however, it is not the very first field in bluenet_ipc_ram_data_item_t. This means that if anything changes, e.g. the type of checksum, etc. we can't communicate this by a protocol bump.

We should just consider the protocol field part of every message. That doesn't mean it has to be written for every message. That's up to the interaction between the sender and the receiver. For example, the microapp might trust bluenet not to overwrite the index and other fields as well.

The recommended version would be split in a major and a minor. If the major is different none of the fields can be used. If the minor is different, the fields known till now can still be used.

typedef struct {
	uint8_t major;
	uint8_t minor;
	uint8_t index;
	uint8_t dataSize;
	uint16_t checksum;
	uint8_t data[BLUENET_IPC_RAM_DATA_ITEM_SIZE];
} __attribute__((packed, aligned(4))) bluenet_ipc_ram_data_item_t;

This fixes an issue when the bootloader is using a newer struct (for the information it sets in IPC RAM) than bluenet.

Edge case

Note that when the major changes, it still means that bluenet has no clue what the bootloader meant. That means that if there is a major change in the protocol between bootloader and bluenet, first a new version of bluenet has to be released (which can handle both protocols) before a new bootloader can be released. Then when the bootloader is released it has to be made depending on that version of bluenet.

If we don't want the bootloader depending on a recent enough firmware, we have to bake in the flexibility in the bootloader. Depending on the version of the firmware it will send other information. This is not recommended though. The bootloader should be lean.

Then, we can just assume that the bootloader will always use the latest bluenet firmware. We always release simultaneously. The only edge case then would be then that after the bootloader updates itself (which erases the application), it fails in uploading the new application. The only thing we have to ensure then is that no fallback scenario is implemented where an old application will be uploaded.

Severity

This information is in any case a "nice to have". If everything fails the app can tell bluenet to go into DFU mode and we can reach the bootloader. We just don't have the bootloader version (or other bootloader info) available in bluenet.