chore(workflow): notify authors with write access to not use forks

[pranav-new-relic]

(not urgent, drafting this PR for consideration sometime)

This PR adds a workflow to validate PRs from forks by authors with repository write access, and block them via the workflow, compelling them to shift to contributing via the actual repository by means of an automated comment.

TL;DR see "2" in Testing to see what I mean :)

Problem Statement

Currently, this repository receives pull requests from both internal collaborators and external contributors. Some internal collaborators who have write access to the repository occasionally create PRs from forks instead of using branches in the main repository. This is not intended, and creates the following problems:

1. Limited CI/CD Pipeline Execution: When PRs come from forks, most integration tests and workflows don't run automatically due to security constraints and cost considerations, which is why we need such authors to contribute from the original repository and not the fork.
2. Inefficient Review Process: Without complete test coverage, maintainers can't fully validate changes, leading to delayed merges or additional manual testing; which also explains why we need to tell them to not use the fork, and use the original repo instead.

Solution

This PR introduces a new GitHub Action workflow that automatically identifies when a PR from a fork is created by a user who already has write access to the repository. The workflow then:

1. Detects if the PR author has write access (either directly or through team membership)
2. Posts a helpful comment explaining the preferred contribution workflow
3. Fails the check with a clear explanation

How the Workflow Functions

The fork-pr-author-validation.yml workflow:

1. Triggers: Runs on pull_request_target events (opened, reopened, synchronize) specifically for PRs from forks
2. Permission Check: Uses GitHub API to determine if the author has write access:
   • First checks direct collaborator permissions
   • Then checks team membership and associated repository permissions
3. Notification: If write access is detected, posts a friendly comment explaining:
   • Why creating PRs from forks is problematic for internal contributors
   • The preferred workflow (creating branches directly in the main repository)
   • How this impacts testing and the review process

Testing

These changes have been tested on a different repository https://github.com/newrelic/test-oac-repository, to allow for flexible testing (without having to use this repository). While additional workflows also run on PRs in this repository allowing for extra automation, please ignore those comments - all details of changes tested are as follows.

1. When a PR is created on the original repo (not fork)

• The check is skipped, as the workflow is configured only to run on PRs from a fork of the original repo
• chore: nothing test-oac-repository#43

2. When a PR is created from a fork of the repo, and the author already has write access to the repo

• The check is run as the workflow runs on PRs from forks, and fails as the author has write access to the original repo
• A comment is added, requesting the author to raise a PR with the original repo, and close this PR
• chore: do nothing from a user with a fork, with write access to the original repo test-oac-repository#44 (comment)

3. When a PR is created from a fork of the repo, and the author does not have write access to the repo

• The check is run as the workflow runs on PRs from forks, and succeeds as the author does not have write access to the original repo
• chore: do nothing from a user with a fork, no write access test-oac-repository#46