log when resolution and address proofing are throttled (LG-4430)

[mitchellhenke]

Adds a couple more throttle events, and some additional detail to be able to distinguish events using the same throttle key

[zachmargolis]

LGTM

[stevegsa]

Not sure it's in the AC but how about logic to only log it once when the limit is reached? (vs on every retry)

[stevegsa]

On second thought we can just query distinct. Probably better to log it.

[stevegsa]

Flip flopping again. Def better to know if they hit the limit separately (and only once for the window). Hitting the limit, waiting the window and getting throttled again should be separate from 2 tries when throttled in one window.

[mitchellhenke]

We don't have a good way to only log once unfortunately. We initially had the event fire when the throttler incremented to be on the final attempt, but since it's possible for the final attempt to succeed that wasn't a great way to capture that someone was throttled. We typically only have throttler checks at the beginning of an action, which means it can happen multiple times :/

For reference, this builds on work from #4829

[stevegsa]

We could have two separate events or one event and a boolean which indicates they are retrying and still throttled

[stevegsa]

"We don't have a good way to only log once unfortunately." - We'd have to keep incrementing the throttle and do a check but that's a big change. I'll go ahead and approve

[aduth]

Is it intentional to omit the step_name from this one?

[mitchellhenke]

This check happens before a step or anything is reached, so step_name doesn't exist