Companion: don't split UTF-8 characters when truncating received message

[ikeruco29]

So I figured out a bug where an emoji might transform the string into a defective string. To put an example: A message is 149 characters of text followed by Hello 🔋, for a total of 159 bytes. Only 156 bytes fit in the frame. The emoji 🔋 is 4 bytes: F0 9F 94 8B.

Current code: it cuts at exactly 156 bytes and keeps only the first byte of the emoji:

OLD: 156 bytes, last bytes: 65 6C 6C 6F 20 F0
                            e  l  l  o  ␣  ← broken half of 🔋

The app shows something like ...Hello �.

With the fix: the cut lands inside the emoji, so it moves back and drops the whole character:

NEW: 155 bytes, last bytes: 48 65 6C 6C 6F 20
                            H  e  l  l  o  ␣

The app shows ...Hello , which is a valid text.

Now, for the record, I have just figured this out, but, at least the IOS app, handles this by checking the message length before sending it, taking into account the emoji length. My approach is, in case a sender without this kind of verification sends the message, a receiver doesn't receive a bad string.

The only draw I see is that, some emojis that occupies too much due to the amount of attributes such as the tone color an emoji can have, the truncation will may take as valid half of the emoji, meaning it may send the emoji with a slight difference.

3 test created, 3 test passed in WSL.