Add support for context package about go-gerrit

[andygrunwald]

I do think adding a context (deadline, cancel, etc.) functionality into a lib that communicates with a 3rd party service is crucial for any kind of reliability and production systems.
Hence, I consider it as worth breaking backward compatibility for.

On top of this: The migration path is rather simple.

About the release question:
I did not thought about this in particular, however, it would be good.
Maybe adding a bit more planning into it and looking into current gerrit versions to see what should be supported as well.

[Jille]

Passing the context as the first parameter is the general recommendation in Go. However, it'd be backwards incompatible.

github.com/xanzy/go-gitlab went the route of adding a ...options to every call and have a gitlab.WithContext() to allow it.

[andygrunwald]

Two additional notes from @Jille from #115

Passing through deadlines in the X-Gerrit-Deadline header
Pass some extra information about that one request to my custom *http.Client

About the implementation in particular:

Afaik there are two possible ways, which are used as a (kind of) standard in Go.

...options

(the one you mentioned). Like

https://github.com/xanzy/go-gitlab/blob/c45201aeba7efc73e1b3c31f14a11cd7851b9327/avatar.go#L51

Adding context as first param

Like

https://github.com/google/go-github/blob/697804fa0c8abebdfaa79ae8e7393d03de6ab86f/github/apps.go#L233

Right now, I don't have a hard preference for the one or the other.
...options would give us more flexibility, but I ask myself, if we really need this flexibility?

Whats your take on this @Jille and @dmitshur ?

[Jille]

You can always add the flexibility if you want it for something else later.

Have you been thinking about releasing a v1 version of this library? That might be a good moment to break backwards compatiblity and require ctx as the first param everywhere.

IMHO the long term option you want is having ctx as the first param, but the question is whether it's worth breaking backwards compatibility for.

[Jille]

Did you think of any other features you wanted to include in v1?

[andygrunwald]

@Jille I don't have a particular roadmap for this project (yet). I am not 100% sure what should be in v1. On the other half, v1 is only a version number. This library is used in many projects already.

This change just needs to be done. I can take this on, once I find the time. I am also happy to accept PRs on this one.