Always process state changes below TOP_THRESHOLD

Sometimes, we deliberately send a process-state TOP change before the
normal oom adjuster update gets triggered for resuming activities. In
this case, there may be a duplicate notification for the same
process-state change with a newer procStateSeq. We need to ensure we
always process these notifications and notify activity manager on
completion.

These are redundant notifications but should be rare and cheap enough to
always process - even if they do not end up changing any of the firewall
state.

Also modifying the log in ActivityManager to report a wtf whenever the
wait timeouts to help emphasize this discrepancy.

Test: atest FrameworksServicesTests:NetworkPolicyManagerServiceTest

Fixes: 327303931
Change-Id: I4884072bd6d7820acee67851d7504886564e2348