Do not pull back locked issues/PRs in scheduled events queries

[JimSuplizio]

Locking the issues after 90 days is a brand new rule. It's also the end of a long path (requiring 90 days of inactivity after 7 and then 14 days of inactivity respectively). As it turns out, after an issue has been closed and locked someone can come back and reopen the issue but leave it locked. The problem with locked issues is comments can't be added which is what most of our scheduled tasks do. This was causing processing failures. The correct solution is to modify the query to omit locked issues from the results. It's also worth noting that these queries should have been omitting locked items from the query result to begin with. Notice that the LockClosedIssues only ever looks for issues that aren't already locked which is what the other queries should have been doing to begin with.

[weshaggard]

@JimSuplizio one other thought here is if an issue is locked but open should we consider unlocking or closing the issue?

[JimSuplizio]

@JimSuplizio one other thought here is if an issue is locked but open should we consider unlocking or closing the issue?

Adding @jsquire since this is probably something he's going to want to mull over.
This shouldn't be a common occurrence but when it happens it'll happen because of someone with permissions doing something. Being that we really don't know their intent, I don't see us being able to do something automated. We certainly do not want to unlock or re-close the issue. Having a scheduled task unlock the issue is going to ultimately play tug of war with the scheduled task that locks the issue. We could possibly do something with things that are both open and unlocked which would at least start the chain again but it's unclear if we should.

[jsquire]

I'd agree that when an issue is reopened, the conversation should be unlocked. Ideally, the folks reopening the issue would remember to do that, but I suspect that it will be forgotten. I'm in favor of adding a rule to catch this.