Don't process own community description on control node side

[MishkaRogachev]

Discovered here: https://github.com/status-im/status-desktop/issues/14700#issuecomment-2108858650

The problem

Every time a community control node performs an action (accepts a join request, adds a channel and etc), a control node dispatches the CommunityDescription message, which supposed to be handled by community members. But the community management node also receives and processes this message. This message is processed in the receive thread (redirected from messenger_handlers.go) and if a locked commiunityLock is encountered during the processing, the receiver thread will hang until the lock is released. Before the optimisations this used to happen during community reevaluation, now this issue can occur with any other long operation that locks commiunityLock and sends community description.

The minimal reproducible scenario can be discovered here

Proposal for fixing

The solution is to ignore the control node's own communityDescription (or ignore its own messages altogether), but at the very least this requires a lot of refactoring of the test infrastructure and verification of the desktop and mobile client that they are getting actual data from the rpc response and not the signal that is generated by receiving the communityDecription

[MishkaRogachev]

@osmaczko @mprakhov @jrainville kindly asking to check if the task description is correct