Fix BLE white list issues

Fix BLE white list issues

Since Bluetooth 4.2 and errata ESR08 there may not be more than one
connection between two LE device addresses. Also the stack assumes
there is at maximum one connection to the same address. This patch
makes sure there are no connected devices in the white list when a
connection attempt is started. Since some (even 4.2) controllers don't
handle this correctly, currently this method is used regardless of
controller in this patch.

When the maximum L2CAP connections were reached and a new connection
was established to a device using auto connect, the stack hung and
would no longer create new connections until Bluetooth was restarted,
since the state change to BLE_CONN_IDLE was forgotten. This patch
resets the state correctly, and also never initiates a connection
unless there is space to avoid connect-disconnect loop.

There were also bugs in the background_connections hash map; memory was
not freed when an element was erased and an incorrect hash function
which used the pointer to a bd addr instead of the bd addr itself which
basically meant that elements were never removed. This patch removes
the dynamic memory allocation and uses a correct hash function.

There was a bug that might lead to that the white list was filled
beyond its maximum, due to the counter was updated on the HCI command
complete event, which might run too late. Now the space is instead
calculated based on what commands have been sent to the controller.

The address type of the address added to the white list must also be
tracked, otherwise it might be updated due to a BLE scan, and later the
wrong address is removed from the white list. This patch fixes this.
(Preferably 49-bit bd addrs should be used as identifier through the
whole stack but we're not there yet.)

There was a queue of size 10 with pending white list operations. That
queue got full if there was initially 10 devices in the white list,
then the 10 devices were removed and immediately after 10 other devices
were added. This patch removes the queue altogether by instead syncing
against the background_connections hash map.

Bug: https://code.google.com/p/android/issues/detail?id=219910
Test: stress-testing with a bunch of BLE devices and inspecting HCI log
Change-Id: I78de654ffbea5f4962a189caf984f7f2934e8fbe