Fix .goreleaser to work with new unified versioning

We no longer split library and cli versions.

attack: Add -max-workers flag (tsenart#421)

* attack: Add -max-workers flag

This commit introduces the `-max-workers` flag and associated function
options. This allows controlling the concurrency level that vegeta uses,
but can sacrifice reaching the requested `-rate`, in case the specified
max number of workers is below the what is needed to sustain such rate.

* Updated README

* Update README.md

attack: Measure latency when requests timeout (tsenart#404)

Fixes tsenart#402

Introduce Pacer interface, ConstantPacer and SinePacer. (tsenart#400)

* Introduce Pacer interface and ConstantPacer.

The Pacer interface allows vegeta's attack rate to be customized.
Attack code keeps track of the elapsed attack duration and the number
of hits sent and provides these to Pace, which must return a Duration
for the attack code to sleep for before sending the next hit. Pace may
also return true for the second stop value to terminate the attack.

This interface allows vegeta to model a wider range of attack scenarios,
such as diurnal request patterns or load-test behaviour, where the
attack rate increases until the target begins to serve errors.

* Add SinePacer, for sinusoidal attack rates.

SinePacer is a Pacer that describes attack request rates with the
equation Rate = Mean * Amplitude * sin(Offset + t * (2𝛑 / Period)).

Both the Mean and Amplitude rates are expressed with ConstantPacer.

attacker: Simplify timeout configuration (tsenart#397)

* attacker: Simplify timeout configuration

This commit simplifies the timeout configuration internally to make use
of the `http.Client.Timeout` field which didn't exist when this code was
originally written.

It also fixes tsenart#396: a test flake of `TestTimeout`.

* Update lib/attack_test.go

refactor: Use t.Fatal instead of t.Error

This commit changes instances of t.Error followed by an immediate return
with t.Fatal, where valid.

Up until today I thought that t.Fatal didn't run defers.

I was [wrong](tsenart#386 (comment))
as @dominikh pointed out.

refactor: Use t.Fatal instead of t.Error

This commit changes instances of t.Error followed by an immediate return
with t.Fatal, where valid.

Up until today I thought that t.Fatal didn't run defers.

I was [wrong](tsenart#386 (comment))
as @dominikh pointed out.

refactor: Use t.Fatal instead of t.Error

This commit changes instances of t.Error followed by an immediate return
with t.Fatal, where valid.

Up until today I thought that t.Fatal didn't run defers.

I was [wrong](tsenart#386 (comment))
as @dominikh pointed out.

attack: Force monotonic timestamp marshalling (tsenart#377)

* attack: Force monotonic timestamp marshalling

This commit forces result timestamps to be monotonically increasing.

This is necessary because the built-in monotonic time reading of the standard
library time package is discarded when marshalling a time.Time instance.

This can lead to non-monotonic timestamps in vegeta results of a single
attack.

Although an explicit decision as stated in the time package documentation,
this assumption seems surprising to me.

From: https://golang.org/pkg/time/#hdr-Monotonic_Clocks

> Because the monotonic clock reading has no meaning outside the current
> process, the serialized forms generated by t.GobEncode, t.MarshalBinary,
> t.MarshalJSON, and t.MarshalText omit the monotonic clock reading,
> and t.Format provides no format for it. Similarly, the constructors
> time.Date, time.Parse, time.ParseInLocation, and time.Unix, as well as
> the unmarshalers t.GobDecode, t.UnmarshalBinary. t.UnmarshalJSON, and
> t.UnmarshalText always create times with no monotonic clock reading.

* Add github.com/gavv/monotime to Gopkg.*

* fixup! Remove redundant monotime dependency

attack: Force monotonic timestamp marshalling (tsenart#377)

* attack: Force monotonic timestamp marshalling

This commit forces result timestamps to be monotonically increasing.

This is necessary because the built-in monotonic time reading of the standard
library time package is discarded when marshalling a time.Time instance.

This can lead to non-monotonic timestamps in vegeta results of a single
attack.

Although an explicit decision as stated in the time package documentation,
this assumption seems surprising to me.

From: https://golang.org/pkg/time/#hdr-Monotonic_Clocks

> Because the monotonic clock reading has no meaning outside the current
> process, the serialized forms generated by t.GobEncode, t.MarshalBinary,
> t.MarshalJSON, and t.MarshalText omit the monotonic clock reading,
> and t.Format provides no format for it. Similarly, the constructors
> time.Date, time.Parse, time.ParseInLocation, and time.Unix, as well as
> the unmarshalers t.GobDecode, t.UnmarshalBinary. t.UnmarshalJSON, and
> t.UnmarshalText always create times with no monotonic clock reading.

* Add github.com/gavv/monotime to Gopkg.*

* fixup! Remove redundant monotime dependency