the remote contact address if not null when the call state is
StreamRunning or Paused and the conference is in state Created or
CreationPending

Add "LeaksMemory" to "Core restarts as soon as chat room is created"

Adapt video call quality tests to take into account changes in network simulator and available bandwidth estimator.
Fix initialization of NatPolicy that could be left orphaned in case of remote provisionning with default_values.

Removed code delaying rotation update in Core (no longer needed) + improved use of handlers to use the same one the Core was created on and thus prevent deadlocks

Fix bug where the push_parameters string read from the configuration files for accounts was deleted and replaced by the core's push notification config all the time, instead of only by default

Allow NULL particiant device joining time. This is required because the
joining time is the time the device state switches to Present, therefore
it is NULL when the device is added to the chatroom or conference

- Add table conference_info_participant_params to store participant parameters instead of putting them as a string in conference_info_participant
  Change participant role from Unknown to Speaker during the migration
- Do not use table conference_info_organizer anymore and move its content to table conference_info_participant
- Delete MainDbPrivate::selectConferenceCallEvent as unused

ChatMessagePrivate::setParticipantState and
ChatMessagePrivate::setState.

All event regarding a chat message will now chat the state of a
participant and then if neecesary the state of the chat message will
follow.

For IMDN controlled stats (i.e. DeliveredToUser, NotDelivered and
Displayed), the state of the chat message will be deduced based on the
states of all participants

For non-IMDN controlled states, the state of the chat message will
follow the state of the me of the chat room the message it associated
with

when initiating a call;
- from header
- account
These 2 parameters are dependent from each other which makes tricky for
the core to know exactly which account to use and the correct from
address.
In most scenarios, the from address is the account's identity address
but it is not always the case such as in the case of a direct call.
Moreover, the account cannot be always deduced in a straightforward
matter such as if the core has no default account (but it is registered
with one or more accounts) and the call parameters have not set one.

The algorithm for choosing an account is the following:
1) search in the call parameters
2) get the default account
3) look up for the best guessed account based on the from (if known) or
   to address

The algorithm for known the from address is the following:
1) look for the from header in the call parameters
2) look up for the identity address of the account (if known)
3) get the core primary account

Set Ik SDP attribute based on the account used for a call

Use account set in the call parameters before retrieving the NAT policy.
It may happen that a call session is buuild without passing an account
and in such a case, the SDK will do its best to get one

- Speaker -> participant has been added by an admin through a REFER
          -> participant has called the conference and all other participants are speakers
- Listener -> participant has called the conference and there is at least a listener being part of the conference

Look if there is a conference info matching the to address in the database in order to know if a call will be part of a conference even if the call cannot be started right away if ICE candidates have to be gathered firt

Wait for the call to onFullStateReceived before updating the conference informations when parsing a NOTIFY full state. This allows to optimize database accesses

Fixed crash on Android if native audio is enabled by androidx.media dependency isn't declared in app

Added a method on ChatMessage to get our own reaction if any + fixed address storage in DB for chat reactions causing multiple devices with same identity to have multiple reactions to same message

Fix an audio issue happening after disconnection of a bluetooth headset, on Mac. Implement automatic reloading of audio devices.

  - Add callback to notify the application that a participant has changed role in the conference
  - Take into account role when creating the list of participant informations of a conference
  - Give priority to the conference information stored in the database over that cached in the call log object
  - When a participant is added, give the application a pointer to it with all the informations up to date
  - In the event of a full state, reduce the number of database accesses by updating the conference information in the callback onFullStateReceived. Previously, for every participant added a DB access was required in order to update the conference information

Tests:
  - Add verification of role and sequence id of every participant info in the conference information in the call logs and conference information
  - add helper functions to ease checking of conference informations

Compared to release/5.2, the fix had to be re-worked.