meta: merge stalebot and update timings/messages

[RedYetiDev]

This PR will consolidate the feature-request and pull request stalebots into a unified workflow that targets all issues and all pull requests.

Focusing solely on feature-request issues seems unnecessary, as other issues can also become stale.

Instead of relying on @mhdawson's fork, which has been great, this PR will update the stale-bot to the latest version (v9.0.0).

However, there's a trade-off. Without the fork, the stalebot loses the endDate controlling environment variable. To address this, I've set the stale timeout to a middle ground between the endDate and the stale timeout (8 months).

Previously, the check was for issues older than a year with no updates in the past 6 months. Now, it will check for issues without any updates in 8 months. The middle ground would technically be 9 months, but I think 8 months strikes a good balance in this case.

[nodejs-github-bot]

Review requested:

• @nodejs/actions

[mhdawson]

I'm have to refresh my memory in terms of how the endDate helpd us meet our requirements. I think it was to meet what we had agreed in terms of handling what to consider stale.

I think https://github.com/nodejs/node/blob/main/doc/contributing/feature-request-management.md will need an update.

[targos]

We should also be careful about the impact. We don't want everyone to suddenly have 500 new notifications.

[mhdawson]

+1 to what @targos said, I was very careful to avoid that when I introduced it in the first place.

[RedYetiDev]

We should also be careful about the impact. We don't want everyone to suddenly have 500 new notifications.

Yes, that is a lot off issues :-/, WDYT should be done?
https://github.com/nodejs/node/issues?q=is%3Aopen+sort%3Aupdated-desc+updated%3A%3C%3D2023-08-29+-label%3Astale+-label%3Anever-stale+

[mhdawson]

That in part is why I added the end date. If I remember correctly I very carefully moved that a bit at a time so that we would not get a flood of notifications.

[RedYetiDev]

That in part is why I added the end date. If I remember correctly I very carefully moved that a bit at a time so that we would not get a flood of notifications.

Still, if we look at issues older than a year, it's a large portion of issues, and no matter the end date, floods may still occur.

[RedYetiDev]

After looking at the stalebot docs, there is a parameter https://github.com/actions/stale?tab=readme-ov-file#start-date, so we could only apply this change to newer issues, to prevent the flood of notifications

[RedYetiDev]

Also, in v9.0.0, the stale API now uses the Actions Cache, which will decrease the time it takes to run and the amount of API operations it performs.

Based on the issue cache from the help repo's first run of the new stalebot, I estimate that ~209 to ~409 API operations will be spared.