starting point for docker builds on MRs/branches, which should speed
up those builds in most cases

[ci] test building the Docker image

See merge request !2

add a special test which runs the functional tests against a baseline
recsystem running in a Docker container

Limit when pipeline jobs run

See merge request !1

workflow or rules

this makes it clearer what's going wrong if the caller does not pass all
arguments as keyword arguments (JSON-RPC only allows all positional arguments
or all keyword arguments, but annoyingly not both)

particularly against their JSON-RPC interface

while these tests are not useful for testing the recommendations themselves
(see the explanation in test_recommendations--this is something implementers
of individual recsystems are responsible for testing--it does provide a good
smoke test as to whether the recsystem has implemented all the JSON-RPC
interfaces correctly

it is designed to in principle be run against any recsystem written in any
language

the test itself is written in Python and requires Python + pytest to run, but
it runs the recsystem itself in a subprocess and can be adapted to any
executable providing the recsystem under test

currently this is not used by the backend, and is only used for testing, so in
principle it is not required to be implemented by all recsystems

however, it may be useful for debugging and testing

includes a class for running the server in a thread, and sending RPC requests
to the recsystem over websockets when the recsystem is attached

this can be used particularly to test the RPC API against an arbitrary system
by sending it particular RPC calls and testing the response

I will request this to the admins

in documenting ArticleCollection.__getitem__ I realized it didn't
actually work as I intended for slicing with article_ids larger than
any in the collection, so that's fixed as well

further refactoring of websocket_test_server to make it easy to create
websocket clients for testing with; since much of the code is shared
with websocket_test_server I further split it up so most of the code
could be shared by the client and server sides

this also helped fix a corner case in WebsocketsMultiClient

refactored the test helper function websocket_test_server and moved the
threading-related code to a new helper function websocket_test_server_thread:
the details of this helper code obscures the purpose of the test, and also
may be useful in additional tests

works as expected

implemented a bit of refactoring to allow connecting to websockets over
a UNIX socket instead of a TCP port; for testing using a UNIX socket is
a little less hassle (no need to find a free port)

JSONRPCServerWebsocketClient class that implements the asyncio loops

the long name is to make clear that this implements a websocket client,
which once connected to the websocket server provides a JSON-RPC server

everything in this code is almost completely abstracted from the details
of Renewal, allowing this code to be tested independently of the Renewal
details

includes updating the minimal Python version to 3.7 to match the backend (this
is not a strict requirement for recsystems in general, but it is for use of
this package)

the base class implements the low-level (e.g. websocket client) functionality,
a basic CLI, basic RPC methods (actually just 'ping' for the moment)

the BaselineRecsystem need only implement the initialize() method and the
remaining RPC methods, as well as slightly extend main() to add the --mode
option

contestants may either subclass RenewalRecsystem to start with bare functionality
and build up from scratch, though they may be able to get started quicker by
subclassing BaselineRecsystem and modifying it (especially the recommend() method)
with their algorithms

in the previous release

package

first attempt at rewriting the baseline as a class, which seems to work fine;
next round will be to factor out some of the low-level details into a base
class

any default metrics stored on them

user assignments during initialization

implement correct handling of article interactions, including updating the
local cache of articles to maintain accurate article metrics

* fix __getitem__ for a single article ID
* fix checking `article_id in articles` by implementing __contains__
* add iteration over ArticleCollection (not explicitly needed at the moment,
  but if someone did try to iterate over it it wouldn't have worked properly
  before)

now in addition to random recommendations it can support recommendation based
on a simple popularity metric; this opens the possibility of adding still more
recommendation modes as well

for the baseline recsystem

from a file

anything that writes a token to a file ought to take care not to write trailing
whitespace; however, this code should be more flexible in case the writer of the
file was neglectful

*only* article IDs when recommendations are requested, rather than the full
article documents

the web server then makes a database request for articles based on those
article IDs; this way the backend is fully responsible for ensuring that
the article documents returned to the app are correctly formatted; otherwise
recsystems would have been free to insert any content they want into the
articles

I believe this design was the original intent, but I got sloppy while
prototyping.

this does not yet implement all features; in particular it does not
implement user management

for the random baseline user management need only be very minimal
since for all users it only returns randomized results (though it
should still try to track past recommendations so that it does not
send users duplicates)

it should also serve as a template from which participants can
implement their own recsystems, though that template might later
be factored out to a bare non-functioning template from which other
recsystems can inherit--TBD