Add keep alive to tcp socket

[jagonalez]

Description

This PR adds keep alive to the socket used to connect to a Faktory server. (see contribsys/faktory#316 - the author recommends using keep alive to protect against timeouts)

Unfortunately the socket library does not have a simple way of setting socket options in it's connectTo method. So instead we're using connectFromSocket and copying some of the code from socket's connectTo method to set the keep-alive.

Testing

To test this change run the examples here: https://github.com/freckle/faktory_worker_haskell#examples
or test a producer and worker used within your application

[pbrisbin]

Going to tag in @eborden to review please -- this is a bit above my networking pay-grade.

[pbrisbin]

It seems like we could try to upstream some kind of connectToWith to connection that takes a function to call at this point, then redefine connectTo as,

connectTo = connectToWith $ const $ pure ()

And we could use connectToWith $ \sock -> setSocketOption sock KeepAlive 1.

[pbrisbin]

On second thought, extending ConnectionParams to have some kind of "setup socket" field would probably be cleaner. Though, since that type is exported by the module, that change would be a major version bump (whereas what I described above would not).

[eborden]

@pbrisbin I agree. I would not like this code to live in this library. It would be much better placed upstream. However I see nothing wrong with enabling KeepAlive.

[eborden]

There is an old issue open speaking about this

vincenthz/hs-connection#48

@vincenthz has been inactive in that repo since 2019, so it is possible connection is unmaintained.

[pbrisbin]

Just to clarify, I was suggestion we still merge this work, but seek to remove it later by pushing upstream.

Given the inactivity though, maybe we just accept it has to live here?

[eborden]

I know this is a near direct copy of resolve from connectTo, however SockAddr is never actually used outside of this context. The only reason to keep this tuple would be to avoid any additional divergence in this copied function.

Suggested change

	return (sock, addrAddress addr)
	return sock

[eborden]

Overall the socket bits here look totally reasonable. I would hope that we can upstream some of this, but I won't hold my breath. I'm good to merge with green tests.

[pbrisbin]

Going to migrate this into a new PR as our test suite doesn't work on forks (needs secrets for the test faktory image).

Thanks for the contribution!

[pbrisbin]

Migrated to #89