Move read_buffer guards in Socket

[vasi-stripe]

Socket#read_nonblock currently has a guard around selecting on the socket in the HTTP case. This makes sure that if we have any data, we don't block waiting for more, but just return it right away.

However, the HTTPS case does not include such a guard. This PR proves that this is mistaken, but running streaming tests in SSL mode, and showing that they fail without the guard, but pass once it's added.

We also remove the superfluous guard in read_block, since it doesn't make sense. In blocking mode, @read_buffer is unused and will always be empty—checking if it's empty is harmless, but complicates the code and achieves nothing.

Best reviewed commit-by-commit:

• Commits 1-2 prepare for running streaming tests in multiple modes (HTTP/HTTPS), by factoring out these tests into a method, and moving it to test_helper.rb
• Commit 3 adds a small bespoke SSL streaming server, and runs the streaming tests against it
  • I couldn't find any simpler way to run an SSL streaming server, other than writing it myself. WEBrick doesn't like streaming, Unicorn doesn't do SSL without a proxy, Thin has a weird streaming model that I don't understand. Ideas welcome!
  • Here's the test output we get as of this commit. Note the SSL streaming tests fail, because once we've read "Hello" we get a "would block" error and wait for more data—instead of returning what we have right away, as a non-block socket should.
• Commit 4 fixes the above test failures, by adding the guard. Now if we have some data, we return it instead of waiting.
• Commit 5 removes the superfluous guard in read_block, since @read_buffer will always be empty in blocking mode

[geemus]

Thanks for your help and all the details, definitely makes it easier.

I'd love to say I know of an easier or cleaner way to setup for tests, but I don't off hand. Getting servers to behave and/or misbehave in the ways we want for tests has been one of the bigger challenges at times with all of this, so we usually have just done whatever we could figure out that would work. Maybe we will revisit that at some point to simplify and streamline in some way, but what you've done seems fine for now.