Update mKeyIsWaitingForEventsTimeout separately from the prune check

Before this CL, the variable mKeyIsWaitingForEventsTimeout was getting
updated inside 'shouldPruneInboundQueueLocked', but that is not the
correct place to do this update. In this CL, we move this update to the
enqueue function, and this allows us to make
'shouldPruneInboundQueueLocked' const.

The current behaviour of:
```
When there are unprocessed motion events, we wait up to 500 ms to send
any key events, in anticipation that focus might change. However, if
there are subsequent "ACTION_DOWN" events, we don't want to be adding
this 500ms wait, so we short-circuit the timeout and process the pending
keys immediately (send them to the currently focused window).
```
is not changed in this CL.

However, we are updating the test for this behaviour to:
- Be correctly named. The pending key is not dropped, but it's processed
  immediately instead.
- Actually test the behaviour in question. Previously, the test passed
  even with the 'mKeyIsWaitingForEventsTimeout' not getting updated
  during the queueing stage. This is because the test used a large
  (1000ms) timeout for event consumption. So in practice, the test was
  still waiting for 500 ms and only then the consumption passed.

In this CL, the test is changed so that it consumes within the allotted
timeframe. If this becomes problematic (flaky), we would need to change
the KEY_WAITING_FOR_EVENTS_TIMEOUT and possibly provide that value from
the policy, thus allowing the test to override it. Or, another way to
fix flakes here would be to switch to an injectable clock, although in
that case we would still ideally open up KEY_WAITING_FOR_EVENTS_TIMEOUT
for tests, or maybe just hardcode the value with a comment, similarly to
how it's currently done.

Bug: 294553757
Test: TEST=inputflinger_tests; m $TEST && $ANDROID_HOST_OUT/nativetest64/$TEST/$TEST
Change-Id: Ife71634960b365df1d106fd28f0dc0047ac2ed2b