core: add 502 errors to retry logic

[stephenplusplus]

Our system tests have been flaking out again. We previously implemented retry logic with exponential backoff to try to resolve the problem. I'm wondering if we need to loosen what triggers the retry logic.

Currently, we check if the status code returned is: 429, 500, or 503. This PR adds 502 to the list, "Bad Gateway", as an attempt to resolve this consistently failing test when run on Travis (but not locally):

1) datastore querying the datastore should select projections:
   Uncaught Error: Bad Gateway
    at Object.parseApiResp (lib/common/util.js:9:5290)
    at Object.handleResp (lib/common/util.js:9:4578)
    at IncomingMessage.<anonymous> (lib/datastore/request.js:9:15948
    at _stream_readable.js:908:16

[callmehiphop]

Do we actually want to retry requests for bad gateways? If we do great, but I'd rather not add this code if it is only to work around Travis.

[stephenplusplus]

I don't actually know. We currently support:

• 500 The server encountered an unexpected condition which prevented it from fulfilling the request.
• 503 The server is currently unable to handle the request due to a temporary overloading or maintenance of the server. The implication is that this is a temporary condition which will be alleviated after some delay.

And 502:

• 502 The server, while acting as a gateway or proxy, received an invalid response from the upstream server it accessed in attempting to fulfill the request.

(http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html)

[stephenplusplus]

@jgeewax any idea if we should we run our retry logic when the server responds with a 502?

[jgeewax]

I think this is reasonable (to retry when we get a 502) as the request (as far as we're concerned) is perfectly fine, but the server behind the proxy had an issue...

[stephenplusplus]

Sounds good. Thanks!