Edge-case: some PRs being omitted from release summary

[ssolbeck]

I've discovered an oddity / edge-case of this action when determining the PRs included in a release, which results in some PRs being omitted from the release summary in certain situations.

The edge-case is due to the behavior of the associatedPullRequests request (doc-link is for the REST API but matches GraphQL API): https://docs.github.com/en/rest/commits/commits?apiVersion=2022-11-28#list-pull-requests-associated-with-a-commit

Lists the merged pull request that introduced the commit to the repository. If the commit is not present in the default branch, will only return open pull requests associated with the commit.

release-drafter queries for the first 5 associated pull requests on each commit. In cases where release-drafter is used on a non-default branch, and PRs are long-lived and often updated via merge, the first 5 associated pull requests may include only other pending PRs, and not the merged PR which introduced the commit.

Proposal

Increasing the number of associated pull requests queried should avoid this issue. If there's any concern that this increase would impact the action's performance, we can implement it as a new optional config option, and keep the default limit at 5.

I'm filing this issue to gauge receptiveness before I write a PR here for the behavior. Please let me know -- I'd much rather contribute to this upstream project than keep a fork.

---

Context

1. We are triggering the release-drafter action on updates to staging, a non-default branch.
2. Feature PRs are merged to staging, and may wait there for some period of time before being merged to main, the default branch.
3. While waiting for release, other open feature PRs may merge staging into their feature branches in order to resolve conflicts.
4. This means that the commits of a feature PR may be present in several other PRs before reaching main.

Reproduction

1. Configure release-drafter to run on pushes to a non-default branch staging.
2. Create a feature branch feature1 off of staging, make a commit on the branch, and open a PR back to staging.
   a. Repeat this four more times, for a total of 5 feature branches and PRs.
3. Create another feature branch feature-in-release off of staging, make a commit on the branch, and open a PR back to staging.
4. Merge this feature-in-release PR into staging.
5. Observe that the release-drafter action is triggered, and that the output release summary includes an entry for feature-in-release (as expected).
6. Update feature1 by merging in staging (keeping this feature branch up to date)
   a. Repeat this four more times for the remaining feature branches.
   b. All five open feature branch PRs will now include the commits from feature-in-release (in addition to other commits).
7. Manually rerun the release-drafter action (or trigger it by making any unrelated push to staging). Observe that the output release summary no longer includes an entry for feature-in-release.