Enforced Google's specification regarding back-off mode

[3kt]

Back-off mode implementation, accounting for both database updates and full hashes lookups, as described in #77 . I think having the back-off mode owned by the database was a design flaw in the first place, since it didn't account for fullHashes.find. I moved the handling to the API itself, which allows consistent behaviour, for both lookups and updates. The only side effect is that, on failure, the database update method doesn't get a clear time horizon for retrial. I worked around that by setting a default 1-minute retry frequency. Since everything is checked internally, it doesn't generate unwanted traffic, but has the only downside of causing unneeded additional operations.

[colonelxc]

@cpu I think these changes might affect you, want to make sure you see it.

[cpu]

@cpu I think these changes might affect you, want to make sure you see it.

Thanks for the tag :-) I took a look at the PR and don't have any major feedback beyond what you shared. My use-case is opportunistic and doesn't benefit substantially from a way to block on readyness or to find out when a lookup retry may succeed again. My use-case does rely on the sb.WaitUntilReady function to know when the database has been updated initially to begin servicing requests but it doesn't sound like this PR will affect that.

[yuzqhorya]

No comment