Fix block of event bus

[pfeuffer]

Proposed changes

This fixes a deadlock that occurs whenever a repository that was imported from another repository with existing pushlogs receives a post receive repository hook.

This deadlock occured,
because on the event the PushlogManager creates a semaphore based on the id of the repository. After the pushlog has been written, the manager tries to find and unlock this semaphore based on the repository id stored in the pushlog. If the repository is an imported one with a pushlog that has been created beforehand in the original repository, this stored repository id differs from the actual id of the current repository. Therefore the semaphore has not been found and the lock stayed in place.

Whenever a second event has been fired for such a repository, the manager cannot pass the semaphore, because it still is locked. This can lead up to a complete block of the core event bus of SCM-Manager so that no asynchronous event whatsoever can be processed any more. This is the case, because the event bus does not call hooks of the same type (in this case the PushlogHook) in parallel. Therefore all further pushlog hooks will have to wait for the event that has been blocked in the first place, which will eventually block all threads of the event bus.

To fix this, this commit removes the redundant and error prone repository id from the pushlog and uses the id of the repository the event was triggered for in both places, the lock and the unlock of the semaphore.

Because a removed fields are ignored by the xml parser loading the pushlog enties, we do not have to adapt the data in an update step. The repository id (and while we're at it the unused 'dataVersion', too) simply will be omitted whenever the pushlog is changed for a repository the next time.

Your checklist for this pull request

Put an x in the boxes that apply. You can also fill these out after creating the PR. If you're unsure about any of them, don't hesitate to ask. We're here to help! This is simply a reminder of what we are going to look for before merging your code.

Contributor:

• PR is well described and the description can be used as a commit message on squash
• Related issues linked to PR if existing and labels set
• New code is covered with unit tests
• New/updated ui components are tested inside the storybook (module ui-components only)
• Changelog entry file created in gradle/changelog
• Feature has been tested with different permissions
• Documentation updated (only necessary for new features or changed behaviour)

Reviewer:

• The clean code principles are respected (CleanCode)
• All new code/logic is implemented on the right spot / "Should this be done here?"
• UI changes fits into the layout
• The UI views / components are responsive (mobile views)
• Correct translations are available

Checklist for branch merge request (not required for forks)

• Branch is green/blue on Jenkins
• Quality Gate passed on SonarQube