Add automatic release of inactive claimed assignments

[Urgau]

This PR adds a system to automatically release inactive claimed (claim and assign <username> commands) assignments.

The logic is loosely inspired by Zulip's bot. We check after inactivity_reminder days the last update on the issue and linked PRs (via the cross-references), we post the reminder message and if nothing moves inactivity_limit - inactivity_reminder days later we remove the assignment and post a comment.

It's configured like this:

[assign.check_activity]
inactivity_reminder = 6 #days
inactivity_limit = 7 #days

Output for the reminder:

Hey @Urgau, just checking in! It's been 6 days since the last update on this issue or linked PRs.

No worries if you're busy! If you still want to tackle this, just drop a quick comment below. If you've run out of time or interest, you can release it by commenting @rustbot release-assignment so another contributor can jump in.

If we don't hear from you in 1 days, you will be automatically unassigned.

Output for the release assignment:

Hey @Urgau, just letting you know we've freed up this issue since we haven't seen any updates for 7 days. If you find the time later on, feel free to reclaim it and pick up where you left off.

Context: #triagebot > Releasing lingering assignments
cc @samueltardieu

[Kobzol]

This is a pretty complex piece of functionality, I kinda wish we had bors' infra here, with that it would be relatively simple to implement robustly 😆

View changes since this review

[Kobzol]

Jobs are not handlers, and even though I know that there are some jobs inside the handlers module currently, I don't find that very readable. What do you think about having a separate module (directory) for jobs?

[Urgau]

What do you think about having a separate module (directory) for jobs?

Conceptually I like the idea, but when the handler and the job is so tightly integrated into each other I think it's better to have them close to each other.

[Kobzol]

If it's implemented like this, it won't help clippy much, because they will still have 100+ legacy assigned issues for which the check won't trigger.

With this implementation, the number of jobs will scale with the number of claimed issues, which means that over time we might have hundreds or thousands of jobs in the repo, and I don't think that's really necessary.

I would prefer a different system, where we have a single job per repo (which has the config activated), which runs e.g. once per day, and checks all claimed issues. I guess that the problem is that triagebot is probably not really architectured to have such jobs at the moment 🤔

[Urgau]

I though of doing a once per day job, but that has several issues:

1. clippy currently has 2500 issues, just getting all the issues and assignees for them is probably going to cost us our 5000 req/h ratelimit, that not even counting getting the PRs, the pulls links, ...
   1. it also wouldn't scale for rust-lang/rust which I think we also want to handle, and it has >10 000 issues
2. we only want to handle assignee's via claim/assign commands, not manual assignment, which would be difficult (impossible?) to support

So for those reason I think having small targeted jobs is better than cron-like job.

they will still have 100+ legacy assigned issues for which the check won't trigger

Yeah, that's unfortunate. I think someone is gonna have to go through all of them and unassigned them manually (with a copy/paste text should be "quick").

[Kobzol]

Most of those issues are unassigned (https://github.com/rust-lang/rust-clippy/issues?q=is%3Aissue%20state%3Aopen%20no%3Aassignee), so maybe we could fetch only the assigned ones? https://docs.github.com/en/graphql/reference/issues#input-object-issuefilters

Or maybe better, simply record claimed issues in the DB, which makes the whole thing much simpler, and solves the issue 2. (which is annoying to deal with using GH API only, we'd have to check IssueData on each issue to see if it was claimed).

[Urgau]

I re-rewrote the whole logic as daily cron-job that checks all the opened issues. I haven't tested it, and it's a little rough on the edges.

Unsure if it's simpler, I will let you be the judge of it. ;-)