There is a possibility where BlueZ initiate an A2DP connection just
around the same time as the peripheral also initiate it.

One scenario is the peripheral initiate the connection first, so
confirm_cb() on /profiles/audio/a2dp.c is called. However, while we
are waiting for the authentication step, BlueZ initiate a connection
to the peripheral, therefore a2dp_sink_connect() is called, which
from there a2dp_avdtp_get() is called.

If this happens: When calling confirm_cb(), chan for the
corresponding device is created.

Then when calling a2dp_avdtp_get(), chan will be found as it is
created in confirm_cb(), and the value of chan->io is not NULL.
However, a NULL is supplied instead to create a new session and
assigned to chan->session.

Then when calling connect_cb(), chan->session will NOT be NULL, as
it is assigned in a2dp_avdtp_get(). Nevertheless, chan->session is
always assigned a new value.

These cause failure in connection.

Therefore, fixing this by supplying the value of chan->io inside
a2dp_avdtp_get() (it's going to be NULL on the normal case so it is
fine), and check whether chan->session already assigned inside
connect_cb().

This allows to display a 16-octet key to be entered on the remote
device during provisioning.

This fixes a bug that didn't allow 16 octet Static OOB strings during
provisioning.

Not all distributions include all required mesh crypto support.  This
adds a section with known kernel required options.

This change adds a configuration for platforms to choose a more secure
posture for the HID profile.  While some older mice are known to not
support pairing or encryption, some platform may choose a more secure
posture by requiring the device to be bonded  and require the
connection to be encrypted when bonding is required.

Reference:
https://www.intel.com/content/www/us/en/security-center/advisory/intel-sa-00352.html

HOGP 1.0 Section 6.1 establishes that the HOGP must require bonding.

Reference:
https://www.intel.com/content/www/us/en/security-center/advisory/intel-sa-00352.htm