Don't lose commits within change detection with event-based triggers - Corner case

Case:

• There is a Bitbucket remote event trigger in the queue waiting for change detection
• The change detection for this trigger is started
• The next commit to the repository is made
• The 2nd commit-related trigger event is rejected because the corresponding trigger is already in the queue and is being executed.
• There is a time window (e.g. post-processing after the git fetching process finishes for the first commit), where the trigger event for the second commit is still rejected even if the change detection for the first commit does not contain the changes from the second one
• Build lose - the single occurrences triggers like remote triggers won't even be retried (e.g. polling is ok because it will be added on the next interval)