gap: Introduce AdvertisementPayload.ServiceUUIDs()

[mook]

This adds a new method that returns all of the Service Class UUIDs found in the advertisement payload. This may require allocating a new slice of UUIDs, hence using HasServiceUUID where possible is still preferred.

Fixes #363

I have no idea what I'm doing, so please review the rawAdvertisementPayload implementation harder; I'm just adapting the HasServiceUUID code. I assume since go.mod claims go1.20 using the conversion in NewUUID is okay.

Please let me know if you'd like me to make changes; if you feel like making the directly that's fine too.

[deadprogram]

Hello @mook thank you for looking into this.

If you could please add some tests for the new functions into https://github.com/tinygo-org/bluetooth/blob/dev/gap_test.go that would be greatly appreciated!

[mook]

Thanks! Tests added. That raises some questions, though:

• NewUUID takes bytes in the reverse order of UnmarshalBinary (and Bytes); when should each be used?
• When implementing rawAdvertisementPayload#ServiceUUIDs, should I actually combine 0x03 and 0x02 (complete and incomplete lists of 16-bit UUIDs), instead of preferring the first? Similarly for 0x07 vs 0x06 (complete and incomplete list of 128-bit UUIDs). How about 0x05 / 0x04 (32-bit UUIDs)? Currently rawAdvertisementPayload#HasServiceUUID just ignores it.
• Can I assume that the advertisement payload will not have multiple of the same EIR data type? Or should I actually just enumerate all EIR data instead? (Apologies if I have the terminology incorrect, I have no idea what I'm doing with respect to Bluetooth.)

[mook]

Rebased; the relevant files had no changes, so there were no merge conflicts.

While the tests pass, it's probably still best if #364 (comment) gets resolved before merging.

[deadprogram]

Thanks! Tests added. That raises some questions, though:

• NewUUID takes bytes in the reverse order of UnmarshalBinary (and Bytes); when should each be used?

The Bluetooth spec tell us that this array is always little-endian.

• When implementing rawAdvertisementPayload#ServiceUUIDs, should I actually combine 0x03 and 0x02 (complete and incomplete lists of 16-bit UUIDs), instead of preferring the first? Similarly for 0x07 vs 0x06 (complete and incomplete list of 128-bit UUIDs). How about 0x05 / 0x04 (32-bit UUIDs)? Currently rawAdvertisementPayload#HasServiceUUID just ignores it.

That might be a kind of bug? Let us address that as a future PR.

• Can I assume that the advertisement payload will not have multiple of the same EIR data type? Or should I actually just enumerate all EIR data instead? (Apologies if I have the terminology incorrect, I have no idea what I'm doing with respect to Bluetooth.)

Given how small the size of data is, we can probably assume no duplication in this packet.

[deadprogram]

Now merging, thanks for working on this @mook