Revert distinguish PR status for kogito-runtimes

[shubhbapna]

Hi we will need to revert this due to an issue that github itself hasn't fixed.

The way action-surefire-report or action-junit-report publish/annotate test failures is using github's check api. Whenever a workflow is run it creates something called a check suite which contains check runs. These check runs are responsible for letting us update github action status. Now these actions give us 2 options to update github action status using check runs - use existing "in_progress" check runs or create a new one.

1. Using existing check runs: We can't use existing check runs since by the time surefire gets to analyse and publish results the workflow which triggered the surefire analysis would have changed its status from "in_progress" to "success/failure". Moreover all our workflows have same job names (eg: Maven Build) which is used as the check run name. This confuses the surefire action from choosing which check run's status it needs to update. We could just try by changing the job name for each workflow but then again there is more complexity added and I think at this point I should try it on simpler repository
2. Creating a new check run: If we let surefire create a new check run then it randomly picks a check suite. Given that we have multiple workflows, the results can be published on any one of them. This makes it difficult for us to find them. Here is an example of my test PR's result being posted on a non-triggered workflow (pr-backporting workflow) - https://github.com/kiegroup/kogito-runtimes/actions/runs/4104153366/jobs/7080599708

Both these problems seem to be known issues:

• JUnit report sent to wrong build mikepenz/action-junit-report#40
• Report check item appears under the wrong workflow name ScaCap/action-surefire-report#39

The creating check run option would have worked but github api does not let us specify the workflow id we want to create the check run for. It only lets us specify the head_sha but again we can have multiple check suites associated with it since we have multiple workflows triggered for a PR. This has been documented in the community but there hasn't been an update from Github for years now:

• https://github.com/orgs/community/discussions/14891
• https://github.com/orgs/community/discussions/24616

I do have some workarounds in mind but I think it is better to try them on a simpler repository. Until then we can keep the surefire.yml (we should disable the workflow tho) and the kogito-pipeline changes since they shouldn't impact the existing PR checks once this PR is merged

[mareknovotny]

@Ginxo here we go back just fyi