Server mode

[bede]

This would be useful for real-time applications including dashboards and nanopore adaptive sampling where index loading overhead is intolerable. Need to consider API design and whether to use JSON/HTTP or something like protobuf/gRPC.

Request format could be either raw FASTA/Q or a (id, seq) tuple?
Response format could be an (id, n_hits, n_minimizers) tuple?

Suggestions welcome.

[bede]

@JeremyWesthead and @RagnarGrootKoerkamp have contributed (#41, #45) respective HTTP and socket-based servers, eliminating warmup time (HashSet construction) for consecutive filter operations, useful for low latency applications. These both address a common problem in different ways. The HTTP server PR runs over a network and is currently feature gated. It was forked before the switch to Paraseq parsing and work allocation. The socket server on the other hand cannot run over a network (AFAIK), but is extremely lightweight and already merged into latest main.

Given that the socket server already covers a key local use case, I intend not to merge Jeremy's relatively complex PR and instead create from it a new repo named deacon-server or similar, with a view to packaging on bioconda to ease current distribution pains (cc @nick297, @ngochieu642). This would compile by default with the server feature meaning the conda binaries would be fit for purpose. If classification parity with the main repo is required we can achieve this, but it will likely lag behind this repo which is still changing a lot.

Any objections?