Enable RabbitMQ to accept SSL connections in addition to plaintext on all Travis-CI and AppVeyor builds

[vitaly-krugl]

I would like to fix/clean up SSL support in pika. Could you please help by enabling RabbitMQ to accept SSL connections in addition to plaintext on all Travis-CI and AppVeyor builds? Also provide rudimentary documentation where the client test code can find the necessary artifacts (e.g., public cert).

Please make sure that the certs never expire or at least don't expire for many years.

See https://github.com/pika/pika/blob/master/docs/examples/tls_mutual_authentication.rst and https://github.com/pika/pika/blob/master/docs/examples/tls_server_uathentication.rst for examples.

We would also need some reasonable strategy for users who run the pika test suite in their own environments. Perhaps the tests discover the location of the test cert via a specific well-named environment variable and skip if said environment variable is not defined or some such thing?

[vitaly-krugl]

@lukebakken, I am working on fixing pika's SSL code paths and am blocked by this issue. I created this issue from my comment in #744.

[lukebakken]

I'm working on this now. It looks like Travis CI runs RabbitMQ on an ancient version of Erlang (R16B03), so this will not be a trivial thing to implement.

[vitaly-krugl]

@lukebakken, as a stepping stone, would it make sense to enable anonymous SSL/TLS connections to be made to RabbitMQ (assuming python's ssl supports it)? Such connections should not require certificates. I am hoping that this might be a lot easier/quicker to orchestrate in the build systems while still allowing a fair amount of testing of pika's SSL support to be implemented.

[lukebakken]

I've got TLS testing working on my pika-981 branch as you can see here. It seems like a new test is failing randomly on pypy. I should be wrapping up Windows today as well.

[vitaly-krugl]

Yeah, that test "Setup 5 timeout handlers and observe them get invoked one by one" has been flaky. I am guessing that the test machines are very slow which sometimes causes a conflict with the selected granularity of timers. Since it's a unit test, it should be mocking time.time() for control and speed of execution instead of slowing down the testing by making the test wait for the actual timeouts in real time.