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