Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>

The interface is now passed to "sendMessage" instead of a serialized
message, which will make possible to customize the "id" property (still
to be added) if needed before sending the message.

Note that, for consistency, the interface was applied to all "overall"
data objects, even if some of them are only for received messages (like
"ErrorOverallWebSocketMessage").

Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>

WebSocket messages may contain an "id" property used to match a response
message with its request.

Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>

Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>

With the external signaling server, if the "id" property is set when
sending a signaling message the response to that specific message will
be identified by the same id. Now a callback can be passed to
"sendMessage", which automatically adds an id to the message and makes
possible to run the callback when/if the response to the message is
received.

Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>

When joining a room, the signaling server confirms that joining the room
was successful by sending a "room" message. Until now the Android app
assumed that "room" messages were sent only in that case, but a "room"
message can be sent also if the properties of the room change. When the
room is joined while the call activity is active the call is also
joined, so if the properties of the room changed while in a call the
Android app rejoined the call, which caused strange issues due to how it
was done. For example, when a recording started additional guests
appeared in the UI.

To solve that now only the "room" message that actually confirms that
the join was successful, which can be identified by setting an ID in the
request to join the room, is treated as such.

Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>