Merge lp://staging/~nikwen/account-polld/authentication-penalty-count into lp://staging/~ubuntu-push-hackers/account-polld/trunk

This also fixes the example case provided in the description of LP: #1383298. However, it does fix the "Connection errors should not increase the penalty count" part.

I tested this now and found that this does not work yet. I'll fix it though. ;)

After better understanding the account-polld code, I now think that we can solve the "reauthentication" (aka retrying to poll the account with a previous auth failure as that results in reauthentication in case of token expiry and in ignoring temporary network issues) in a better way.

Yet, merging this one will fix the problem experienced with the current implementation, so I vote for doing so right now, but I will still prepare a better version based on this one as soon as possible that is tackling only the "reauthentication in case of token expiry and ignoring temporary issues" part instead of all auth errors.

Ok, given that the auth errors are passed from C instead of being native Go errors, I think that this will be harder than I though. Partly revising my previous statement, I'll have to see how easy the "ignoring only temporary issues" part is going to be.

That confirms me in my suggestion to get this preliminary (but working!) solution in for now.

One idea would be to manually select those that we want/don't want from libsignon-glib's signon-errors.h.

The last commit should fix a race condition I found while testing. I'll report back tomorrow if it is gone now.

Tested it for a day and it seems to work fine now. :)

Do you have a way for me to confirm the fix, i.e. a way to trigger the aggressive polld behaviour?

That's actually a very good question.

I often get an auth failure after rebooting my phone because it tries to authenticate before the phone establishes a network connection. You could try that and set down the authTriesUntilPenalty to 1.
Otherwise, you could try letting it run in the background for some time and your Gmail tokens will at some point have to be refreshed. However, this is always just one auth failure instead of the many from the bug report. As I noted over there, I currently don't have any idea how to reproduce that kind of behaviour. Maybe changing your Gmail account password might work... (The real password without updating it on the phone.)

What I *can* confirm though is that this doesn't break anything. I've been running it for more than a week now and I've got notifications just fine and the logs look good when a token expires. ;)

I can confirm that it doesn't break anything, but from using the new steps to reproduce (which I hope replicates the bug accurately), it doesn't fix the issue either. :|

Maybe your fix fixes an authentication failure, but not a token expiry (which _easily_ causes endless loops, and is seen all over the logs attached in bug 1496773)

Looks good, works well!

Thanks for approving! :)