No need to maintain two different pieces of logic - a `utcnow()` for
Python < 3.11 and `now(datetime.UTC)` for Python >= 3.11.
`datetime.timezone.utc` existed long before datetime.UTC and that's what
the `utcnow` facade should use.
This means that all the `utcnow()` will always have `tzinfo=UTC`
regardless of the Python version.
There's still a problem with the `utcnow()`-generated timestamps that
have been generated by previous versions of Python and stored on the db.
Therefore, when the code performs comparisons with timestamps fetched
from the db, it should always explicitly do a `.replace(tzinfo=utc)` to
ensure that we always compare offset-aware datetime representations.
See blog post for technical details:
https://manganiello.blog/wheres-my-time-again
`datetime.utcnow` may be deprecated on Python >= 3.12, but
`datetime.UTC` isn't present on older Python versions.
Added a `platypush.utils.utcnow()` method as a workaround compatible
with both.
1. Check the manufacturer parsed via Bleak/Theengs
2. Check the MAC address prefix in the oui numbers table
3. Check from the reported `manufacturer_data`
- Merged together Bluetooth legacy and BLE plugins and scanners.
- Introduced Theengs as a dependency to infer BLE device types and
create sub-entities appropriately.
- Using `BluetoothDevice` and `BluetoothService` entities as the bread
and butter for all the Bluetooth plugin's components.
- Using a shared cache of devices and services between the legacy and
BLE integrations, with merging/coalescing logic included.
- Extended list of discoverable services to include all those officially
supported by the Bluetooth specs.
- Instantiate a separate pool of workers to discover services.
- Refactor of the Bluetooth events - all of them are now instantiated
from a single `BluetoothDevice` object.
Fabio Manganiello