Resolving an issue with local_name being blank on Windows 11

[azimuthdeveloper]

Hi, and thanks for this excellent BLE library!

On Windows 11, there is an issue with local_name not being populated at device scan time. This seems to be because Windows devices possibly do not observe the local_name property in the advertisement packet.

This PR resolves the issue by calling BluetoothLEDevice::FromBluetoothAddressAsync to specifically retrieve the local_name for the device in question. In my testing, the local_name property is now set 100% of the time at device discovery.

However - the BluetoothLEDevice::FromBluetoothAddressAsync call is async while the update_properties function is sync. Because this call is also implemented on other platforms, I've decided to block on this call until it returns, so we don't have to make this function async, and then make all the other implementations async as well.

Also, I started learning rust 2 weeks ago, so my code may be overly verbose, or this might just be a non-smart suggestion, so forgive any weirdness or lame ideas in the PR. Thanks for reviewing!

[qdot]

Ok, so, this is currently held up on a few different issues:

• We shouldn't bring a block_on call in (even though there's a possible sync mutex lock right after it >.> ), but that could be pretty easily remedied by firing the name update as async.
• I don't yet have a Windows 11 box to test this on. Need to make that happen soon.

I'd really like to get this tested and confirmed first, because advertisement packets aren't required to have a local name field in BLE, only address. So it could be that advertisements are updating wrong elsewhere in the library anyways. Using FromBluetoothAddressAsync is going to pull from the system cache if that advertisement data isn't available, which could lead to other possible weirdness.

[ZhouYixun]

Is there any progress in this pr? I have encountered the same problem in Windows 11.