mod_posix: Move everything to util.startup
This allows greater control over the order of events.
Notably, the internal ordering between daemonization, initialization of
libunbound and setup of signal handling is sensitive.
libunbound starts a separate thread for processing DNS requests.
If this thread is started before signal handling has been set up, it
will not inherit the signal handlers and instead behave as it would have
before signal handlers were set up, i.e. cause the whole process to
immediately exit.
libunbound is usually initialized on the first DNS request, usually
triggered by an outgoing s2s connection attempt.
If daemonization happens before signals have been set up, signals may
not be processed at all.
# Basic roster test
[Client] Romeo
jid: user@localhost
password: password
[Client] Juliet
jid: juliet@localhost
password: password
---------
Romeo connects
Juliet connects
Romeo sends:
<presence/>
Romeo receives:
<presence from="${Romeo's full JID}" />
Romeo sends:
<iq type="get" id="roster1">
<query xmlns='jabber:iq:roster'/>
</iq>
Romeo receives:
<iq type="result" id="roster1">
<query ver='{scansion:any}' xmlns="jabber:iq:roster"/>
</iq>
# Add nurse to roster
Romeo sends:
<iq type="set" id="roster2">
<query xmlns="jabber:iq:roster">
<item jid='nurse@localhost'/>
</query>
</iq>
# Receive the roster add result
Romeo receives:
<iq type="result" id="roster2"/>
# Receive the roster push
Romeo receives:
<iq type="set" id="{scansion:any}">
<query xmlns='jabber:iq:roster' ver='{scansion:any}'>
<item jid='nurse@localhost' subscription='none'/>
</query>
</iq>
Romeo sends:
<iq type="result" id="fixme"/>
# Fetch the roster, it should include nurse now
Romeo sends:
<iq type="get" id="roster3">
<query xmlns='jabber:iq:roster'/>
</iq>
Romeo receives:
<iq type="result" id="roster3">
<query xmlns='jabber:iq:roster' ver="{scansion:any}">
<item subscription='none' jid='nurse@localhost'/>
</query>
</iq>
Romeo disconnects