Add API to register callback to set socket options

[nosnilmot]

The registered callback function will be called before connect() is called on the socket, allowing tweaking of much more than just keepalive settings.

This deprecates xmpp_conn_set_keepalive(), which will be ignored if it is called for a conn object that already has a sockopt callback set.

Includes helper/example callback function to set default keepalive parameters that some library users may find useful.

This comes from discussion on PR #199.

Examples have been modified to leverage new API:

• bot.c uses included helper callback to set default keepalive values with new --tcp-keepalive option (also reworked option parsing to match basic.c and complex.c)
• complex.c uses custom callback function (but essentially does the same thing)

sock.c is no longer completely standalone from the rest of strophe, as it needed to know about xmpp_conn_t and xmpp_sockopt_callback We could either:

• live with it? I'm not sure if sock.[ch] are intended to be reusable elsewhere without modification
• move call to callback into conn.c/_conn_connect (I did this originally, but it means callback cannot set socket options before connect() call)
• something else?

[nosnilmot]

Do you prefer I squash commits & force push, or will you squash/rebase during merge?

[sjaeckel]

Do you prefer I squash commits & force push, or will you squash/rebase during merge?

Please always squash/fixup, rebase and force-push!

[sjaeckel]

Can you please check whether I missed something in 163e34d or if that's OK and still does everything we want and discussed?

You could also squash b798e90 into af22d87 if you want to.

[nosnilmot]

Can you please check whether I missed something in 163e34d or if that's OK and still does everything we want and discussed?

hmm, this introduces some subtle behaviour changes:

• TCP_KEEPCNT will be set for any existing users of xmpp_conn_set_keepalive() (this was the case before 5518a9e10add32608a347103e235597da52779ce too, there was presumably some reason it was removed).
• TCP_USER_TIMEOUT will be set for existing users of xmpp_conn_set_keepalive()
• It's no longer possible to differentiate between xmpp_conn_set_keepalive() / xmpp_conn_set_sockopt_callback() and warn about deprecation of xmpp_conn_set_keepalive(). Maybe this isn't critical.

I think the existing behaviour is restored with 0001773a62d6b73ce896b904691c8a06803117bc.

* This function is only effective on a disconnected object.

That's a good point, and slight loss of functionality. Should we call the callback immediately for a connected object? or change xmpp_conn_set_sockopt_callback() to return the socket (or NULL if not connected) so the user can choose?

You could also squash b798e90 into af22d87 if you want to.

Will wait to hear if you want to keep 0001773a62d6b73ce896b904691c8a06803117bc or not before cleaning up / rewriting git history.

[sjaeckel]

I think the existing behaviour is restored with 0001773.

Thanks! Please keep it, squash stuff together and rebase.

* This function is only effective on a disconnected object.

That's a good point, and slight loss of functionality. Should we call the callback immediately for a connected object? or change xmpp_conn_set_sockopt_callback() to return the socket (or NULL if not connected) so the user can choose?

We're not sure whether libstrophe will only have a single socket per connection in the future (some comment from @pasis in the past), so returning the socket is no option. I don't see a reason why we shouldn't call the callback immediately for a connected object. IIRC some of the socket options can only be applied to disconnected sockets, if that's the case we should write down in our documentation that the user has to take care of that!

[nosnilmot]

I think the existing behaviour is restored with 0001773.

Thanks! Please keep it, squash stuff together and rebase.

done.

I don't see a reason why we shouldn't call the callback immediately for a connected object.

added.

IIRC some of the socket options can only be applied to disconnected sockets, if that's the case we should write down in our documentation that the user has to take care of that!

I'd like to think it was obvious that if you want to set options that can only be set on disconnnected sockets, then the callback should be registered before connection, but I have added a note to that effect anyway.