… is None (#1571)

In some situations, device.details has the scan response data only and
advertising data is None.

Since the ble address cannot be obtained from device.details.adv this time,
the ble address is obtained from the device.details.scan (scan response data).

It is quite common for people to report "bugs" in Bleak because they are
using it wrong. Now we can have a link to give them to explain this in
detail.

updated-dependencies:
- dependency-name: requests
  dependency-type: indirect
...

Signed-off-by: dependabot[bot] <[email protected]>

This is a follow-up to a818521 ("backends/scanner: always filter by
service_uuids") to also filter discovered devices by the service UUIDs.

This was overlooked in that change and on Windows actually caused a
regression.

Fixes: #1576

The keys in the descriptor dict are the normalized 128-bit UUID string, so we need to use this to correctly find the descriptor.

Fixes #823

#1581)

In commit 4a653e6 ("backends/winrt: raise exception when trying to scan
with STA") we added a check to raise an exception when trying to scan
when PyWinRT set the apartment model to STA. However, properly working
GUI apps will have the apartment model set to STA but Bleak will still
work because there is something pumping the Windows message loop.

We don't want to raise an exception in this case to avoid breaking
working apps. We can improve the test by checking if the current thread
is actually pumping the message loop by scheduling a callback via a
the win32 SetTimeout function. If the callback is called, then we know
that the message loop is being pumped. If not, then we probably are not
going to get async callbacks from the WinRT APIs and we raise an
exception in this case.

…#1586)

It has been observed that the max MTU exchange may not be complete
before the connection is established, at least on Windows.

This reverts the previous attempt to work around this on Windows and
instead makes the max_write_without_response_size dynamic. This way
users can implement a workaround if needed but users who don't need it
won't be punished with a longer connection time. The timeout in the
previous workaround was also too short for some devices so it wasn't
complexly fixing the issue.