Add support for stream context options with connectors

[DaveRandom]

Fixes #4

[DaveRandom]

Now also attempts to normalize the environment for SSL connections as far as possible.

[rdlowrey]

This is done automatically in 5.6, but you may not care since you still need to do it pre 5.6.

[cboden]

@rdlowrey The intention is to normalize the behaviour between each of the PHP versions to match the changes you made in 5.6.

@DaveRandom Can you trigger another TravisCI build? The re-run button doesn't seem to be an option on PRs.

[DaveRandom]

To summarise what has been discussed in IRC:

• Currently this PR incorporates an alternate implementation of [WIP][RFC] Concept for connection timeout #10, which should probably be separated out into another PR.
• A connect timeout implementation is required in order for this PR to pass Travis builds - probably because the configuration has changed on the Travis boxes so that attempts to connect to unbound sockets on 127.0.0.1 are now silently discarded instead of actively refused.
• The connect timeout implementation uses a "fake" context option to allow for user-defined timeouts. This means that the two implementations are currently dependent on each other.
• The key for the "fake" context option has been arbitrarily chosen as react_socket_client, this needs to be discussed and agreed upon. Whatever is chosen, it should contain a character that is not valid in a URI scheme - underscore _ is a good candidate but requires at least two words or a prefix/suffix.

[egeloen]

What is the state of this PR? I would like to be able to control the socket timeout throught react/http-client :)

[arunpoudel]

+1

Also, isn't it past due date?

[clue]

I like the feature, but I'm not sure I like the API.

Let me quote from related ticket #10:

IMO we should first figure out some use cases for this feature to see how this is actually going to be used.

The socket-client component is quite lowlevel, so it's unlikely to be used by many users directly. It's probably more likely going to be used as part of some high level abstractions (say, a Redis or MySQL client implementation). These high level components depend on a ConnectorInterface and will likely use DI to inject this. They probably care little about how the connector works. Neither should they care about any "additional" parameters. They do care about the target (hostname and port).

Hence (IMHO) they should not have to take care of context options or connection timeouts.

See also the changes in the SecureConnector, most implementations of the ConnectorInterface will likely not care about the concept of "context options" and merely pass these through to their underlying Connector.

As an alternative, I would suggest passing context options to the constructor of the Connector.

[WyriHaximus]

Any news on this? Just got an issue on one of my packages regarding this PR: WyriHaximus/react-guzzle-psr7#4

[clue]

We're looking into pushing an intermediary release and will hence postpone all tickets related to context options to the next release.

See also #45 for an alternative implementation approach.