done the same way as in useSendDMOperationUtils

we can remove it because this is done before calling this function, see thread-reducer.js

this is now done in reducer

Is it possible to expand a little bit on this? I understand that you're just moving the code around here but it would help to be more specific about "dedicated actions", and to explain why we do it this way

Do you think this is better now?

A bit better, but some things are still confusing to me:

1. Do we use processDMOpsActionType to schedule messages to other peers, even for composable DM messages? Or are they two different cases?
2. Do we only care about calculating the reply count during processDMOpsActionType for non-composable messages? Is that because it's handled already for composable messages by a different action?

1. We always use processDMOpsActionType to schedule messages to other peers (this is the only way to do it), that's why dedicated actions are not enough here (for the DMs) and we have processDMOpsActionType too.
2. We have one mechanism for calculating the reply count for DM messages (implemented here in thread reducer) which works regardless of message type (composable or not), and side (sender or receiver).

Looks like this is confusing so sharing some more context:
Non-composable messages, receiver
processDMOpsActionType is responsible for adding messages to the store, and updating the reply count in the thread reducer (getThreadUpdatesForNewMessages), no messages to other peers are scheduled because this is the receiver.

Non-composable messages, sender
processDMOpsActionType is responsible for adding messages to the store, and scheduling messages to other peers, and updating the reply count in the thread reducer (getThreadUpdatesForNewMessages).

Composable messages, receiver
processDMOpsActionType is responsible for adding messages to the store, and updating the reply count in the thread reducer (getThreadUpdatesForNewMessages), no messages to other peers are scheduled because this is the receiver. There is no additional action.

Composable messages, sender
sendTextMessageActionTypes or sendMultimediaMessageActionTypes is responsible for actual sending logic the same way as for the keyserver, we didn't have to rewrite InputStateContatiner, we have tracking status, and retrying implemented. This action also adds a message to the message store.
The only difference is that instead of calling keyserver it dispatches processDMOpsActionType which:

• schedule messages to other peers
• await sending messages to mark the message as a success/failure
• update reply count as all above using getThreadUpdatesForNewMessages
• it can not add a message to the store, it was already added using sendTextMessageActionTypes or sendMultimediaMessageActionTypes, this is why we have the code here (in theory, the message will be merged anyway but for the short period of time we can show two messages on the screen)