Store failure reason for github event when marking it as errored

[begedin]

Closes #873

This is just a basic solution.

Things to discuss, how to enhance

• maybe rename failure_reason -> error_reason/errored_reason
• instead of just storing the atoms the processing code returns, we could map the atoms into "user friendly" actual messages. I feel the atoms are just a layer of abstraction that doesn't really help us.

[joshsmith]

I agree we should probably have some more user-friendly messages.

[joshsmith]

Maybe we should make the column error? Or errors that's an array of them a la changeset errors? Idk if there's ever a reason we'd have multiple errors that we've collected.

Did you want to do the error reason rewrite into user friendly messages here or elsewhere?

[begedin]

I would do that elsewhere, probably something we can work in as we figure out what the common reasons for errors are :)

[begedin]

I don't think we would have multiple errors, unless a changeset is a failure and we want to store the errors from the changeset.

Generally, an errored event happens when the handler module returns an error tuple, so we would not have more than one. The "friendly error" proposal would be mapping the atom in the second tuple element into a string.