Now imapsql module does not handle authentication. (it was not doing it so well
anyway)
sql_table module was introduced and used in the default configuration as
a replacement for functionality that was implemented by imapsql before.
Parts of maddyctl code were rewritten to make it work transparently with
any IMAP backend or credentials store.
Closes#212.
There is abstraction 'updates pipe' defined for future use with
configuration involving IMAP data replication (e.g. multiple nodes with
maddy instances + PostgreSQL replicas + S3 bucket for messages).
However, for the case of local SQLite3 DB, limited UDS-based
implementation is provided. It solves the problem of maddyctl not being
able to tell the server about modifications it makes. Alternative to
this approach would be to have server actually perform operations and
maddyctl being a dumb API client, but this requires a lot more complex
IPC interface and will not work when the server is down.
Now it is not tied go-imap-sql details (with the exception of special
features), allowing it to be used with other storage backends that will
be added in the future.
--unsafe flag is removed and now maddyctl explicitly asks for
confirmation in cases where transaction may be unsafe for connected
clients. --yes flag disables that. In the future, maddy can be
extended with IPC interface to push updates so it this restriction
can be lifted altogether.