(bug/regression) VRC.OSCQuery does not detect VRChat client(s)

[dfgHiatus]

Describe the bug
VRC.OSCQuery does not detect VRChat client(s). Interestingly, running the sample code and/or the code itself in its own project is able to detect a running VRChat client.

To Reproduce
Steps to reproduce the behavior:
This is present in the current version of the app.

Expected behavior
Babble.Net is able to detect and parse avatars advertised via the OSCQuery service.

Desktop (please complete the following information):

• OS: Windows 10 x86
• Version: 22H2

Additional context
I noticed this after I added OSCBundle support, although removing this did not fix the issue.

[dfgHiatus]

Inconsistent. Will report back with further findings.

[dfgHiatus]

Ok. Here is what I was able to find so far:

1. Sometimes, VRChat clients cannot be detected and other times they can. Starting the app before/after VRChat launches does not seem to influence this. Relevant - https://github.com/SutekhVRC/VRCOSCQuery/blob/main/VRChatOSCQueryBugs.md
2. Sometimes, VRC.OSCQuery returns an empty OSC tree, even if a client is connected from Android devices specifically. This is not the case on Desktop.

If we wanted to replace VRC.OSCQuery, we have a few options:

1. Use VRCFaceTracking's OSCQuery implementation
2. Use something like VRCOSCQuery

[dfgHiatus]

Given the above, I have a hacky workaround in place. I'll keep this issue open because it does not/can not resolve the underlying issue, but let me elaborate below. What's supposed to happen is:

1. We receive an "/avatar/change" OSC message from the VRChat client when a user changes their avatar
2. Upon this, we pull down said avatar's parameters via its OSC Tree (via OSCQuery) over a user's local network and determine what Unified Expression parameters we need to send (float and binary)
3. Rinse wash repeat

Instead:

1. "/avatar/change" events aren't fired at all on Android. Workaround: Poll the OSC Tree once every 5/whatever seconds, keeping track of the last _avatarID. If this has changed the user is in a new avatar.
2. As listed above, even if we have found the VRChat client, we don't always get the OSC Tree from it. But! We know its IP and port. Workaround a): Use TheGrandLookupTable to store every float parameter, even the ones VRCFaceTracking "generate(s) at runtime". VRCFaceTracking does not expose combined/negative/boolean Unified Expressions parameters, so we compute those as well.
3. Bundle out packages and pray we don't overload VRChat's OSC, which has been an issue in the past. We could have a message queue and check if it exceeds some threshold, and send it from there and clear the queue. VRCFaceTracking does this internally.

Anyways, this is blocked for the time being. I'll revisit this once VRChat's OSCQuery is more mature.