_bleio.ScanEntry.matches() is too strict for "all=True" matches

[dhalbert]

bleio_scanentry_data_matches() in shared-module/_bleio/ScanEntry.c returns false prematurely if the the first prefix doesn't match the first structure and !any is true. It should try all the structures.

[kevinjwalters]

When fixing this it would be useful to keep an eye on any code which might fail on matching sub-classes of one or two Advertisements. As mentioned in discord, I've had the same code running on three boards which transit to each other and receive each other's broadcasts. Sometimes one goes "deaf" and doesn't pick up a particular sub-classed Advertisement for >15s which is really odd compared to its neighbour which receives them fine. The "deaf" CPB then suddenly picks up the next sub-class in the protocol fine. These all have single prefix matches on the default matching scheme.

I'm also running start_advertising() before and during the start_scan(). And within the program I stop_scan() and then start_scan() again with a new set of classes.

[kevinjwalters]

Actually, I'm starting to think it's my code that's getting out of sync with itself. Now I've got my own matching code I can also see more detail when it doesn't match and I have a very small sequence of different Advertisement types. I accept the current one and one after but not the one before...

Maybe the moral to this story is a debug mode/option would be useful on start_scan() when it's being used to filter Advertisements to show all the incoming message it there's a suspicion matching is failing for some reason?

[Added later]: the problematic code had two issues, there was and is also a strange form of packet loss show in BLE Advertisement strange, acute packet loss.