Optimize broadcasting message

### Is your feature request related to a problem?

Currently there is only one function available to send a message to a node through `Connection.send_message` this function takes a timeout and expect the node to return a response.
But there is some messages that don't need any response and are often used using `P2P.broadcast_message`. This create useless network traffic and message handling as all messages return a response even if not handled by the client node.
Also as the `send_message` function is synchronous and wait the response, the function `broadcast_message` uses extra async task which could create bottle neck for the task supervisor

### Describe the solution you'd like

We could create a new behavior for sending messages which do not require a response.
Connection module could have 2 functions:
- `request` which has the same behavior as the actual `send_message` function
- `send_message` a new function that just send the message to the node and directly return to the caller function

The new send_message function could also free some space in the Connection genserver as we do not need to store the request id and other stuff to handle the future response.

For the target node to distinguish the 2 behaviors, we could add a new boolean byte in the message envelop with true for sending the response, false to not send any reponse. This boolean could be handled by listener protocol to know the action to do after processing the message.

### Additional context

_No response_

### Epic

_No response_

Start by reading Connection.send_message and P2P.broadcast_message, then trace the listener protocol and message envelope handling. The issue names no files or tests; done means separating response-waiting requests from fire-and-forget sends, distinguishing them in the envelope, and removing unnecessary response handling and broadcast async work.

Written by the indexing model from the issue text.