Revert pull_request action back

[miroslavpojer]

This issue is related to:

• Move permissions to job level #333
• abris #329 use pull_request_target to fix PRs from forks #334

Status in time of writing this issue is that we are using pull_request_target instead of usage pull_request in yml files:

• build-scala2.12-spark3.2.yml
• build-scala2.13-spark3.2.yml

This change was needed to be able to merge Approved changes from repository fork.
We were not able to find any better solution in time of change.

Now, when merge is done we are in state where another changes can come inside repository from forks.
It open potential security risk which was solved by simple change configuration for now.

• Configuration change: PR from fork will start GH actions after team member confirmation. This can avoid start of potential dangerous GH action with writing rights.

Fast fix:

• Return back pull_request action to both yml files mentioned above.

Slow fix:

• Invite DevOps colleagues into problem solution and do analysis what changes needs to be done.

[cerveada]

Another idea that could help with this is to split tests and test coverage in separated actions.

• Tests don't need the write permission at all and can happily run using pull_request
• Test coverage require the permission, but even if it fails, we can still asses the amount of new untested code easily. Adding to that - external PRs are usually small, so it's even less of a problem.

[kevinwallimann]

pull_request_target doesn't work like we think. It "runs in the context of the base of the pull request", so it doesn't actually run with the changes from the pull request. It may be useful for tasks like auto-labeling issues, but not to run the build of the PR. It is not a drop-in replacement for pull_request

[cerveada]

In #339 we reverted to using pull_request and separated the workflows for tests and test coverage.