Enable support for different clients
In the current code base the following defintions apply:
- client: connects to the server via protocol (eg. IMAP)
- cache: stores the messages that are retrieved by the client
- backend: combines the client and cache
Currently, there is only one client implementation by Fina. But implementing and maintaining our own client is a lot of work.
There is an open question about whether we can re-use existing client implementations such as email-lib or melib. However, some of these libraries might not support all the features that we need.
Therefore, in order to prevent having long-lived MRs which require constant rebasing, the question is whether we can support parallel client implementations behind a simple interface which can be switched between.
Fina's initial implementation would still be the default while the others are ramped up.
We should be careful about abstracting the interface too much, as abstraction always comes at the cost of complexity, performance and maintenance.
Similarly, we should be disciplined about cutting off such client implementations if significant progress has not been made. The aim will always be to support only one client. But in this initial exploration phase, it would be useful to allow this. The current scope of this is limited to IMAP support.
In order to support this, some refactoring will be necessary for the way the connections are handled. Currently the client belongs to a connection pool. In order to support different clients, we would need to have it the other way around.