Revisit Error Types

[taylortrimble]

There were some comments from #41 that hinted we may wish to revisit error types. I don't have anything specific in mind today, but recommend we review error handling specifically after some of the more major API changes we're considering.

[nathany]

#3, #4, #30, #40

[nathany]

• On develop I added ErrUnrecognizedErrorResponse to differentiate from the ErrUnknown that Apple could send.
• ErrProcessing, etc. are just strings right now. Normally the Err prefix indicates an error type.
• I would probably change ErrStr string to Err error.
• The Error.Command should always be 8, and is therefore doesn't need to be stored.

// Error captures the error response read from Apple's Push Notification server.
type Error struct {
    Status     uint8
    Identifier uint32
    Err          error
}

There are also various low-level socket errors that Read() may return if we don't get an error from Apple:

• There are a bunch of "tls: " errors during a handshake on the first read, but they are just error strings without exported Err constants to compare to.

• There is some mention of EAGAIN or EOF errors.

• There's also an io.ErrNoProgress error. I don't imagine we make many calls to Read though.

  when many calls to Read have failed to return any data or error, usually the sign of a broken io.Reader implementation