Support custom requests session in presto connections

[gthomas-slack]

pyhive supports passing through a custom requests session for advanced usage such as custom headers, cookie values, retry logic, etc - https://github.com/dropbox/PyHive/blob/master/pyhive/presto.py#L115

This PR adds support for passing through a custom requests session to pyhive when creating an omniduct PrestoClient.

[danfrankj]

nit: single backticks here on requests.Session

[danfrankj]

likely we should have the be private (ie. start with an underscore)

[danfrankj]

Hey @gthomas-slack - thanks for this and for contributing to omniduct! A couple nits but nothing significant. I'll let @matthewwardrop comment as well.

[gthomas-slack]

Hey @gthomas-slack - thanks for this and for contributing to omniduct! A couple nits but nothing significant. I'll let @matthewwardrop comment as well.

Thanks @danfrankj ! I've pushed a commit to address those nits

[matthewwardrop]

Hi @gthomas-slack ! Thanks for the patch! Merging it in now! [I'll put out a new release soon].

FYI: Eventually, I had planned to migrate omniduct from using pyhive to the upstream presto-python-client. It's blocked on them adding support for polling, for which I have a PR open (trinodb/trino-python-client#18); but which I've let lie fallow for a while since the world has gone crazy and I don't have a huge amount of bandwidth (and the review cycles on that PR are very slow). For the time being, it looks like pyhive is still being maintained, so there's no harm in continuing to bolster features. If the libraries are not at parity when this migration occurs, assuming it does, then I'll keep the backends switchable (so this patch shouldn't break) :).

[gthomas-slack]

Thanks @matthewwardrop !

Ah interesting - if/when it comes time to fully switchover to presto-python-client I'd be happy to help look into what changes we might need on that side to maintain this support. Thanks again