Add support for scheduled retry with retryAfter

[jeremycolin]

Fixes https://github.com/zalando-incubator/perron/issues/93

Changes

1. retry operation now does not pass currentAttempt as argument. currentAttempt is now actually returned to retry() so that we can use it outside of the current retry operation (for multiple retries in parallel).

2. retry operation now passes scheduledRetry as boolean argument. scheduledRetry helps determine that we need to propagate error when it fails.

3. support for dropAllRequestsAfter which wraps all requests (initial and potential retries) sent and will drop all of them after that time

4. support for retryAfter which enables retrying a request without having to wait for first one to fail and still have it in flight while we send second one

[jeremycolin]

Discussion with @shuhei

• performance.now() or process.hrtime() or Date.now()

• When using the new params, monitor number of open connections.

• This will create more connections, can we run into some limit? limit on File descriptor?

• When aborting request, server (depending on how its implemented) will likely receive and log errors of connections closed prematurely.

• aborting a request vs ignoring: when we simply ignore the request, how is the data handled if not read, does it generate garbage? @NorthFury

• timerLeft concepts can be later enhanced by passing down this information to the server serving the request. Probably we also do not want to send the request if timerLeft is quite low (threshold to define)