Support primary services as a discovery criteria

[Supereg]

Problem

Currently, advertisedService is the only discovery criteria we support. However, devices do not always advertise their primary service. Therefore, a primaryService discovery criteria would be great. Additionally, in development environments it would be equally beneficial if we support a name-based discovery criteria.

Solution

To implement the primaryService is similar to advertisedService with the only difference that we cannot match discovered peripherals to their DeviceConfiguration immediately. We will first need to discovery all their services (or try to discover all configured primary services we are interested) to match their device configuration and then discovering all their services in a second step. So this requires a 2-step service discovery approach which might induce some reengineering and new models in the BluetoothPeripheral actor.

The name discovery criteria requires a different approach. As CoreBluetooth cannot filter by names, we would need to discover all nearby peripherals and only dynamically filter by their name. This has performance impacts and therefore is only recommended in development environments. We might reconsider the importance of this feature based on this impact.

Additional context

No response

Code of Conduct

• I agree to follow this project's Code of Conduct and Contributing Guidelines