Take latency into consideration before regressing an issue

### Problem Statement

When resolving an issue (no release or commit conditions), if that issue receives a new error, it will always be changed into a regression, even if the event received is of high latency.

Customer comment:

> This issue was wrongly marked as a regression when an event with high latency was received.
>
> I would expect the logic to take into account the time when an issue was resolved and the latency when it receives events that were before that time, so it does not mark false positive regressions.

In this case, an issue regarding a mobile error was resolved at 12:04. However, an error that occurred at 08:48 was received at 12:55 due to high latency. This error regressed the issue, even though it actually occurred before the issue was resolved.

### Solution Brainstorm

Take latency into consideration and don't regress issues that receive events that occurred before it was resolved, even if those events are received after it was resolved.

### Product Area

Issues

Start by tracing the issue resolution and regression logic, then inspect how event occurrence time and receipt time are compared. Reproduce the case where an event occurring before resolution arrives afterward; done means it does not regress the issue, while an event occurring after resolution still does.

Written by the indexing model from the issue text.