Wait longer for expected input events

Sometimes, a device can be slow. That means, some events take a long
time to process, especially if they involve kernel processing these from
userspace and sending them back to userspace.

When the input device is being added or removed, we are currently not
waiting long enough to be notified. The test currently fails because the
input device added notification never arrived.

It turns out there are 2 cases where we are currently waiting for an
input event from eventhub:
1) When we know how many events we expect, and we don't care how long
they will take. We are willing to wait for a long time, because we know
they will come eventually. When we got the expected number of events, we
can stop waiting for more
2) When we have no idea how many events to expect, and we don't want to
wait - we just need to take all immediately available.

To account for the 2 (and only the 2 cases above), refactor
EventHub_test to wait for a specific number of events instead of a
timeout. If no expected number of events is provided, read all
immediately available ones without a limit.

This change also makes the test ~ 50% faster, because we are now
stopping the wait after we have received the expected number of events.

Bug: 149155998
Test: /data/nativetest64/inputflinger_tests/inputflinger_tests --gtest_filter=*EventHubTest* --gtest_repeat=1000
Change-Id: I732c14c09567e9231bcc83141368b1614805f9ac