When ToxFile is constructed with a file size of 0, it cancels the transfer as
soon as the first chunk is received due to the received size being
larger than expected.
v0.0.2 of toxext_extended_messages brought in a user configurable max
message size. This changeset implements the minimum work required for
qTox to work sanely under the new API.
* Hardcode a max message size for all friends
* If a friend negotiates a max message size below the hardcoded value
pretend they do not have the extension
* Move splitMessage out of Core to MessageProcessor
* Updates to allow for extended messages to be split
* Introduced ToxExt and CoreExt abstraction
* Along with interfaces for mocking and unit testing
* Add "supportedExtensions" concept to Friend
* Dispatch messages to CoreExt instead of Core when friend supports
extended messages
* Only split messages for core when extended messages are unavailable
* Offline message engine/History not altered. Currently only valid for
an existing session after extension negotiation has completed
* From the archeology I managed, MAX_GROUP_MESSAGE_LEN was a workaround
for an old toxcore bug. Testing removal of this parameter and replacing it
with tox_max_message_length() seems to work fine.
Blocked status will represent friends who are removed from Toxcore, but who still exist in UI and can be readded to Toxcore at a future time using their public key. Blocked friends are similar to offline friends, but have a different status icon and will be seperated in the friends list.
Caused race where peer plays audio, then is removed from group, then we
process audio played signal and lookup their peerId in core where it
doesn't exist. Now Group will effectively contain the peer until the
peer list changed slot is processed.
Partial fix for #5511
Replace double static_cast of pointer with reinterpret_cast.
reinterpret_cast in unsafe because the underlying data may be
meaningless in the new type, static cast to void then to a new pointer
type has exactly the same problem. This is our intention here.
*All friend avatar changes and removals go through Profile, so that Profile can manage identicons
*Split the concept of "changed" and "removed" into "changed", "set", and "removed"
Fixes#4724