pass raw options to faraday

[icambron]

I did this to work around some specific HTTP problem I was having, but it seems like a generally good idea to allow people access to lower-level APIs, just in case there's some Faraday feature they need that isn't in the Twitter gem.

One way to go even further that direction would be to allow the caller to specify their own Faraday middlewares.

[laserlemon]

What, no tests? Also, it might be helpful to do a recursive merge on the faraday options if one wants include a single additional header.

[icambron]

There's an implicit test that checks that setting the option works at the Twitter level. As far as testing that the setting really gets set on Faraday, I'm not sure what the best way to do that is. It's also consistent with the other tests. But I'm open to suggestions.

On the recursive merge, yeah, I agree. Another thing that isn't clear is which way the precedence should go. I made it so that Twitter wins when there are conflicting keys, but the more I think about it, the more I think it should go the other way.

[sferik]

Should I reopen that issue or are you planning to submit a new pull request to address the recursive merge issue?

[icambron]

I think it should be a separate issue, but I'll go ahead and open it, since I don't know when I'll get to it.