add Handle() callback to support Service-specific signal handling

[mreiferson]

This does what I said I was going to do in nsqio/nsq#1331

[mreiferson]

I've pulled in #29 here so I can more easily get a build going

[judwhite]

@mreiferson I usually provide a package level function such as IsErrStop to check error types. It mimics how os handles errors, but it's different than io.EOF like you have here.

I like that the IsErrXXX way takes some of the guess work out, such as the caller asking "Is this the right way to check this error? Can I depend on the author considering errors as part of their API contract?" The Go team is explicit about io.EOF not changing.

I don't have a hard stance for public projects, especially since we don't have to worry about unwrapping. What are your thoughts? I'm open.

[mreiferson]

I usually provide a package level function such as IsErrStop to check error types. It mimics how os handles errors, but it's different than io.EOF like you have here.

@judwhite I'm not sure that cleans things up in this case? The caller (Service provider) needs to return a specific error type to go-svc, not check an error type go-svc returns.

[ploxiln]

Yeah, this is the opposite direction of the usual pattern.

This error returned by the user's callback to this library, is really a kind of sentinel value. It could alternatively be a boolean, or an enum of some kind ...

side note: the commit at the head of this branch is now referenced by https://github.com/nsqio/nsq/blob/v1.2.1/go.mod#L20 so we should theoretically be sure to keep this commit alive in mreiferson's fork indefinitely, maybe on another new branch so that this one can have requested changes rebased/squashed before merge

[mreiferson]

Yep, pushed to https://github.com/mreiferson/go-svc/tree/nsq-v1.2.1