broadcast channel reactions

[r10s]

this PR adds support for reactions in broadcast channels:

• 1. reactions are send from broadcast channel subscriber (Chattype::InBroadcast) to broadcast channel owner (Chattype::OutBroadcast) as usual, the only change needed for that was to allow sending reactions to channels (which have can_send()==false otherwise)

• 2. the broadcast owner receives the reaction as usual, it gets added to reactions table without any code changes, and UI display them without any code changes as well

• 3. to be able to detect the reactions to update at 4., however, we need to add the table reactions_need_broadcast and set it when a reaction is set

• 4. every some minutes, broadcast owner send a single, hidden message with accumulated reactions that happened in the channel the last minutes, for any message in the channel. for affected messages, the whole reaction state is sent, not a diff. after that, all rows with chat_id are removed from reactions_need_update.
  for the wire format, see below

• 5. the broadcast subscriber receives that message and applies the changes to reactions_accumulated. this means that old entries for the given msg_id are deleted first

• 6. unfortunately, the logic of get_message_reactions supporting reactions with count field is in the jsonrpc api, not in core. we have to move that to core before we can adapt get_message_reactions in the next step.

• 7. jsonrpc's get_message_reactions needs to be adapted for channels: the result must be the union of reactions_accumulated and reactions. the latter is still needed so that the broadcast subscriber has a guarantee to see their own reaction even if offline or races occur.
  if is a bit unfortunate that the logic is in jsonrpc and not in the rust part at get_msg_reactions, we may want to put that to rust.

• 8. mute channels for channel owners by default so they do not get notified for reactions - in general, some ppl want these notifications, so they can unmute then. it is even easier in the UI to allow that than what we're doing currently, also telegram allows notifications for channel reactions (but also has them muted by default).
  if it is easier, it is also fine to not notify reactions at all, we'll see if ppl at scale complain

finally, there is some cleanup done, reactions are removed from the (now) debug info; they were added there in a time where not all UI support reactions

wire format

wire format can be a JSON in the body of a mail with the header Content-Disposition: reaction, as rendered already by Param::Reaction.

{
  "messages": [
    {
      "id": "12345678",
      "reactions": [
        { "emoji": "👍", "count": 4 },
        { "emoji": "🎉", "count": 2 }
      ]
    },
    {
      "id": "23456789",
      "reactions": []
    }
  ]
}

for id, the wire format needs to use rfc724_mid as msg_id are local only.

known issues

• if the channel owner uses multiple devices, the reaction updates from 4. are sent from each device. the updates are not that big, so that is probably not a big deal. if it turns out that this is an issue, we can think about fixes in another PR. might be done by setting updated to a timestamp or so, and reset it when seeing and accumulated reaction update from another device

• we cannot set contact_id for DC_EVENT_REACTIONS_CHANGED - but i doubt it was ever used

for another pr

• add Broadcast-Reactions: header also for resent channel messages, so that new subscriber do not only get the latest messages, but also their reactions. for that, the Broadcast-Reactions: header can go to the corresponding message, no need to send extra messages. we would need to change the sending part to send all reactions for a given message. on receiving part, we need to make sure, receive_broadcast_reactions() is called when the message actually exist.

• add api to allow only a subset of reactions, fiter incoming reactions before broadcasting