Avoid obsolete uid-state change evaluations in NPMS

In some cases, where a uid undergoes quick consecutive state changes and
the handler message has not completed execution, we can return early if
we know a following handler message to evaluate the same rules is
pending.

We peek at UidStateCallbackInfos to infer this state as these are
populated directly in the UidObserver callbacks before posting to the
handler.

The code avoids removing messages from the Handler as
- it is a linear operation that may be slower.
- the check on UidStateCallback happens later and returns from redundant
handler message-processing without incurring much additional work.

Also taking out some code out of the mUidRulesFirstLock lock.

Test: atest CtsHostsideNetworkTests
Test: FrameworksServicesTests:NetworkPolicyManagerServiceTest

Bug: 327058756
Change-Id: I764f714d3ce09699a0ab82b77c8b6a577cd9f9ab

0 files changed, 0 insertions, 0 deletions