Send multiple notifications concurrently

[nathany]

closes #31 closes #40

• [x] example of sending notifications concurrently
• [x] build a worker pool into Service
• [x] update README
• [x] review and revise API
• [x] tests for concurrent notifications

[nathany]

If we want this to be the default behaviour, what would that involve?

A Service could have a worker pool. The main thing is that responses are concurrent, so we need a channel in the API? Do we keep the existing synchronous APIs? Do both Push and PushBytes adopt this?

[nathany]

ATM I'm thinking:

• NewService sets up some workers and the channels
• Push and PushBytes take the same params but just queue up a notification (no response)
• A method to close the channel and shutdown the workers
• Response() method blocks for a response and returns (id, *Notification, error)

[nathany]

Should push.notification be exported?

• NewNotification that does marshalling and may return an error
• PushNotification(n)
• Include the whole Notification in Response(), not just deviceToken
• []Notification could be useful for preparing notifications to send

Should pushSync be exported?

Should there be an internal WaitGroup that Shutdown() waits on to ensure all responses have been received?

Using x/net/http2 directly instead of ConfigureTransport could allow support for Go 1.5.x (if desired), and make it so NewClient() doesn't return an error. https://github.com/sideshow/apns2/blob/master/client.go#L60

[nathany]

TODO: write tests that exercise the concurrency (multiple notifications) for testing with the race detector.

Look at where pointers are used or not used and decide which is preferable.

Reconsider how Error responses from Apple are provided. Could make the type conversion to *push.Error unnecessary.

[curtisallen]

Other then a nit pick LGTM 👍

[nathany]

I experimented with NewNotification but I'm not in love with it.

Also still considering supporting a synchronous push.