Workaround for FedMsg storypoint (str) values

[webbnh]

Attempting to actually use the storypoint sync'ing fails because the storypoint value must be a number, and we're (apparently) presenting it as a string.

The problem arises from the fact that, until we merge #207, there is substantial duplication in the source, and the change in #216 to introduce support for storypoint sync'ing covered only the repo-initialization path and not the FedMsg update path.

This PR introduces a stop-gap into the downstream issue code which attempts to force the story point value to be an int, and, if it fails, simply skips the update. Once the upstream/intermediate code is corrected to supply a numeric value (or no value), this conversion can be removed.

This PR also tweaks the downstream code for setting Priority values and improves the logging of errors, and it adds some unit tests to detect these problems.

CC: @baijum

[mattreid]

As part of

This PR introduces a stop-gap into the downstream issue code which attempts to force the story point value to be an int, and, if it fails, simply skips the update.

Does that mean it would still log any error that it didn't match/wasn't able to convert (by commenting on the downstream issue), or it truly skips and we don't get anything indicating that something may have been missed?

[webbnh]

As part of

This PR introduces a stop-gap into the downstream issue code which attempts to force the story point value to be an int, and, if it fails, simply skips the update.

Does that mean it would still log any error that it didn't match/wasn't able to convert (by commenting on the downstream issue), or it truly skips and we don't get anything indicating that something may have been missed?

For the case of story points, it will silently skip the update, and no one will be the wiser...if the input value cannot be coerced to an integer. I think that this is OK, since story points should be numeric, and the most likely reason why it cannot be converted is that it is missing (null, None, or an empty string), in which case we want to ignore it.

For the case of priorities, we were already silently skipping the update for unmappable values, so this doesn't make anything worse. Nevertheless, I concur that the lack of feedback to the maintainers is disappointing. But, balanced against that is the fact that sending errors to the log is not a reliable way to get them noticed, and adding them as comments becomes noisy if they get re-added every time the issue is touched. So, I'm not sure what the best solution here is.

But, this PR is not the "final fix". We can and should implement that after we've DRYed out the code...not before.

[mattreid]

Marking approved from my side, since you were able to get a more technical review than I can provide from @baijum.