To avoid a race where server-started fires before the promise function body is
run (on next tick), I moved server-started to fire on the next tick, which
seems sensible anyway.
Errors are logged, I'm not sure if we ought to be doing something more here.
I'm sure we'll find out.
Ensures a last round of garbage collection and that finalizers are
called. Fixes things like proper closing of SQLite3 state.
There are more calls to os.exit() but most of them exit with an error or
in a case where a final GC sweep might not matter as much.
It would be nice if this was the default.
Calling util.statup.exit() everywhere may be sensible, but would be more
involved, requiring imports everywhere.
Observed problem: When shutting down prosody would immediately exit
after waiting for s2s connections to close, skipping the last cleanup
events and reporting the exit reason and code.
This happens because prosody.main_thread is in a waiting state and
queuing startup.shutdown is dispatched trough the main loop via
nexttick, but since the main loop was no longer running at that point it
proceeded to the end of the prosody script and exited there.
Original motivation was tiresome warnings about Lua 5.4 not being
supported yet.
Can still be handy to tweak log level, e.g. to prevent logging to
interfere with command output.
The 'prosody' global is not global this early so there was no way to
override the process type field or argument parsing settings from
outside, e.g. from the migrator.
Having it relative to current working directory is problematic since
this depends on how Prosody was started and changes to the data
directory during startup (but after this point).
Since this runs before dropping root, the directory ends up being owned
by root, resulting in luarocks failing to install anything, since by
then it would be running as the prosody user.
luarocks creates this directory if needed, so creating it during startup
is not necessary.
One potential issue is if the directory is somewhere where Prosody can't
write, but then you will simply have to create it yourself with the
appropriate permissions.
Improves usability of the console when digging around the internals.
No specific rationale for the function<file:line>(args) format, it
looked best of the variants I tried.
Testing has demonstrated that the default GC parameters are not
sufficient to prevent runaway memory growth when running under Lua 5.2
and Lua 5.3.
Setting the GC speed to 500 was tested on Lua versions 5.1->5.4 and did
not display unbounded memory growth.
It's not so nice to have a library that exits the entire application
from under you, so this and the error reporting belongs in util.startup.
The argparse code was originally in util.startup but moved out in
1196f1e8d178 but the error handling should have stayed.
