Introduces the govcr test recorder

[displague]

Introduces govcr test recorder, disabled by default. "play" mode should become the default once we have recorded sanitized fixtures for all tests.

Also fixes golanglint-ci linter warnings. (see dominikh/go-tools#503 (comment) regarding the for{switch{case<-time.Tick changes)

Also deprecates some precarious public variables: https://github.com/packethost/packngo/pull/193/files#diff-7d1c2a3334601b6c1958aae0a594cba8

[t0mk]

I looked at Facilities.List and saw nothing mentioned there.
We have the list of facilities here to speed up test for whether a facility code is correct.

[t0mk]

dtto for All the other resource listings.

[displague]

I'll change "See" to "Use". I didn't mean for users to find more explanation in the Facilities.List documentation, rather I meant they should not use this static list in favor of the dynamic one.

If we need this for packngo tests we should put it in utils_test.go (or more likely packngo_test.go). FWIW, I didn't see Facilities being referenced at all in this project.

If non-packngo packages are using this variable it's more problematic, because this is an outdated and incomplete list.

[t0mk]

@displague I looked at the code, and wrote some comments, only request for change would be rebase to master, so that the provisoiing events check goes away.

I will now run the tests and see how the recording and playing works.

[t0mk]

Since this PR changes tests, would you mind changing the size iin VolumeCreateRequest from 10 to 100 in all the relevant files (grep VolumeCreate *test.go). 100 is the new minimum size.

[t0mk]

I run tests for email, volume and device and tried to record and play, it worked OK.

The TestAccDeviceBasic test was doing the delays of the API and I honestly don't understand where the delays came from, or how the duration of the delays were recorded.

[displague]

The TestAccDeviceBasic test was doing the delays of the API and I honestly don't understand where the delays came from, or how the duration of the delays were recorded.

HTTP headers return the time that a client should wait before retrying, client-side delays would be against the timer and would wait however long the server requested (between recorded/replayed requests). When we sanitize fixtures we can reduce the delay that the server requested (this can be done in the same place the X-Auth-Token is sanitized).

[t0mk]

@displague Cool! Otherwise this PR looks really good. You introduced a new additional way of testing without breaking anything, that can only be appreciated.