Fixed another list of unstable unit tests in travis

[pierresouchay]

Fixed failing tests in https://travis-ci.org/hashicorp/consul/jobs/451357061 triggered by #4904

@freddygv Will improve a bit the robustness of tests

[banks]

Thanks @pierresouchay we're preparing master for 1.4.0 release so won't merge immediately.

[freddygv]

@pierresouchay I have a couple questions:

1. Why add a wait to the HTTPAPI tests? given that this was the error: Get http://127.0.0.1:49134/v1/agent/self: net/http: request canceled (Client.Timeout exceeded while awaiting headers

2. Also wondering about the wait in the agent/consul tests (like TestServer_JoinLAN_TLS) that had this error: Failed to start TCP listener on "127.0.0.1" port 47542: listen tcp 127.0.0.1:47542: bind: address already in use

Mostly wondering if these changes would have prevented the failures in the build you linked to.

[pierresouchay]

@freddygv

@pierresouchay I have a couple questions:

1. Why add a wait to the HTTPAPI tests? given that this was the error: Get http://127.0.0.1:49134/v1/agent/self: net/http: request canceled (Client.Timeout exceeded while awaiting headers
2. Also wondering about the wait in the agent/consul tests (like TestServer_JoinLAN_TLS) that had this error: Failed to start TCP listener on "127.0.0.1" port 47542: listen tcp 127.0.0.1:47542: bind: address already in use

Mostly wondering if these changes would have prevented the failures in the build you linked to.

I dunno, maybe I am wrong, I added those fixes after failure https://travis-ci.org/hashicorp/consul/jobs/451357061 -> usually, using testrpc.WaitForTestAgent fixes most of unstable tests in travis, so I used the same old trick as I am used to...

(This PR is probably a combinaison of other failures I saw in other Travis builds, I don't remember)

[banks]

I agree that the HTTP options one that is now flaky is due to the timeouts we added (to stop them just hanging forever like they used to). The best fix for those is to add ones that seems to fial often to the "slow" list to get a longer timeout.

All of them take milliseconds when not run in parallel but the cartesian product means over 500 test cases so not running in parallel takes too long for Travis. I kinda want to fix it to be more efficient and.or figure out the ones that have timing issues when run in parallel with others (due to contention etc) but not had time.

This PR seems safe and likely fixes some more cases though so I'll merge for now.