When mod_admin_socket is loaded without mod_admin_shell, attempt to use
`prosodyctl shell` will appear to freeze after any input, since no
response is returned.
user:roles() does not convey that this is the mutating command, it
should have been called setroles from the start but wasn't due to lack
of foresight. This has to accidentally removing roles when wanting to
show them.
Due to the dummy statistics provider (see core.statsmanager line 250)
having a metatable that allows infinite indexing where everything is
always the same table, which end up in suf() in the concatenation line.
Idea here is to prevent a user from being created with the default role
if a different role was given, but that dance wouldn't be needed if no
role is provided.
E.g. module:info("http") with many http modules loaded would show a lot
of duplication, as each module would be listed for each host, even if
not actually enabled on that host.
By creating the account first without a password it can't be used until
the role has set. This is most important for restricted accounts, as a
failure to set the role would lead to the account having more privileges
than indented.
To point out which one when more than one connection was established, or
if it's an existing connection, allows correlation with s2s:show() or
with logs.
For this, various accessor functions are now provided directly on the
sockets, which reach down into the LuaSec implementation to obtain the
information.
While this may seem of little gain at first, it hides the implementation
detail of the LuaSec+LuaSocket combination that the actual socket and
the TLS layer are separate objects.
The net gain here is that an alternative implementation does not have to
emulate that specific implementation detail and "only" has to expose
LuaSec-compatible data structures on the new functions.
The connection events are more appropriate here, where the s2s-created
events happens a bit later or earlier in a sessions lifetime depending
on its direction and for outgoing connections isn't actually the
creation time (which happens immediately after pressing enter, so not
very interesting), but rather closer to the connection time.
As in the argument to user:create() and user:roles()
Tricky to come up with something sensible to write when Prosody core
only knows of the 'prosody:admin' role so far.