Add CMD_SEND_CHANNEL_DATA for binary mesh channel messages

[zjs81]

Introduce CMD_SEND_CHANNEL_DATA (0x60) to send binary payloads over channels via flood routing

Define MAX_BINARY_LEN (164 bytes) from MAX_PACKET_PAYLOAD - CIPHER_BLOCK_SIZE - 4

Add onChannelDataRecv() to receive and queue binary channel data

Route PAYLOAD_TYPE_GRP_DATA in onGroupDataRecv() to onChannelDataRecv

Add RESP_CODE_CHANNEL_DATA_RECV (0x1A) for binary responses

Update protocol documentation with command and response frame formats

Binary format: [timestamp(4B LE)][data]
Response format: [0x1A][SNR*4][reserved][channel_idx][path_len][timestamp][data]

This will allow apps to send binary data for non-text messages. For Example Meshcore opens reactions or gifs.

[liamcottle]

Just a quick comment, can't fully review this right now...

This would need to include some sort of type flag, so official firmware usage can be distinguished from custom app usage. Otherwise if we decided to implement new features using group data packets, it will break those external apps. Could probably reserve type=0xFF for custom binary payloads.

Regarding your note about using it for reactions etc, this should probably be supported by DMs as well, so would likely need to be a new TXT_TYPE_REACTION or something similar.

[zjs81]

My plan was just to do generic binary messages and parse them client side. That way I dont need to make a bunch of msg types. If the offical app would wanna potentally put in support for reactions I could add that message type if thats how we want to do it. We would just have to standardize how we send them out. Right now, I have reactions down to a 7 byte payload if I get rid of the r: and use a magic byte to determine type I could potentally get it down to like 6 bytes. For direct messages I was planning to just use CMD_SEND_BINARY_REQ number 50. Let me know your thoughts.

Thanks, Zach

[ripplebiz]

I'd like to second what Liam pointed out. We really need to have a group_data type/discriminator in there as standard, from day 1. It's one regret I have over the anon_req packet types that I didn't reserve a type field early enough.
For instance, I have some rough sketches/ideas for using group_data for an SOS feature. group_txt doesn't work because the person in distress, after activating, would be sending the SOS on a timer, so group channels would just get filled up with repeats of the SOS.
Also, the whole TXT_TYPE_* mechanism is very underutilised ATM. The intention was for there to be things like 'emoji reaction', survey/poll responses, and heaps more. Please extend into the TXT_TYPE_* space if possible.