Don't re-open completed issues on email reply

[abstractj]

When a mailing list reply arrives for a closed issue, check the state reason before re-opening. Issues closed as COMPLETED stay closed with an auto-reply posted to GitHub and sent via email. SecAlert emails are excluded and always re-open. Introduces an extensible auto-reply template system (AutoReplyType enum + properties file + CDI bean).

Closes #77

[ahus1]

Some time has passed since this issue was opened.

While this sounds reasonable, all examples that I recall are usually replies where we missed sending out a notification to the reporter and the query about the status, we mixed up the attribution, etc.

So unless we have a good list of examples where not re-opening the issue would be the right thing, I would in doubt rather re-open the issue.

The do not re-open the issue when PSIRT sends the final "this issue is now closed" is a different issue.

[abstractj]

@ahus1 I will defer to you and @stianst to decide how to proceed. My take is that: if an issue was marked as completed, means having the fix merged, the reporter should start a new thread. But I'm fine with whatever we agree.

[ahus1]

I agree with the following statement:

if an issue was marked as completed, means having the fix merged, the reporter should start a new thread.

Still, the cases where an issue was re-opened was related to we missing sending out a notification to the reporter, missing attribution, or something else after we moved.

@stianst - If we don't re-open the issue, we will ignore the message. The worst thing would be someone submitting a new CVE, but us ignoring it. To better be safe-than-sorry, I'd like those issues to be re-opened as they are today.

I'm ok to manually close the occasional very rare "thank you" from a reporter.

[stianst]

I had the impression this was a bigger issue than it actually is; seems there's only 8 issues that was closed as completed and has the re-opened-by-bot label (well there was 9, but one was closed as completed by mistake).

6 will be fixed by #82; and the remaining two where as @ahus1 pointed out due to missing notifications to the reporter.

I suggest we get #82 deployed, and leave this one open for a while to monitor the issue before making a call.

[abstractj]

@stianst @ahus1 np on waiting, let's merge what makes sense.

[abstractj]

Converted to draft so we get back into it if needed.

[abstractj]

Closing it for now to reduce the noise, but we can always reopen if needed.