Fix rate-limiting of enqueued notifications

NMS has a rate-limiting mechanism for notification enqueues. In theory, this should stop packages from enqueueing updates (only updates) to notifications at a rate of more than 5/sec.

Also, when a notification is enqueued, NMS waits 250ms for the NAS to do its magic and calculate appropriate adjustments before the notification is actually posted.

This led to some issues with enqueue rate-limiting -- a rogue or malfunctioning app could enqueue as many notification updates are they could fit in this 250ms window, because:
1. Only updates to _already-posted_ notifications were considered updates.
2. The enqueue rate was updated at post time, not at enqueueing time.
3. The calculated enqueue rate catches up very slowly to the actual rate for very "bursty" events.

This CL fixes these issues:
1. Updates to _still-queued_ notifications are also considered updates.
2. The enqueue rate is updated _at enqueue time_, but _only for notifications that get through_ the rate-limiting. This hews closer to the original implementation, and the intent is that packages that post at a constant above the rate-limit (say 8/sec) should still get _some_ notifications through (around half in this case) instead of all of them being blocked.
3. The alpha value of the RateEstimator is tweaked to give more weight to the latest events. Otherwise an app can post one update, then sit idle for a long time, then post a heavy burst, and the estimated rate would take a long time to catch up to the new behavior. This still doesn't mean that a package that posts 6 updates will see the sixth blocked, but the rate calculation is now more sensitive.

Test: Unit tests + manual
Fixes: 280098361
Change-Id: I08568ce90427f18a9b23530cd7b6cbf45b9d9395