Configure Renovate

See merge request !3

WCSP API changes

See merge request uis/devops/utbs/utbs-client!2

Dockerising the build process (based on ibis-client)

See merge request uis/devops/utbs/utbs-client!1

Remove tox test disable upload to PyPI

Deprecating Python 2

Python scripts used in build process ported to Python 3

The old technique was horribly out-dated, and no longer worked on my
machine,
following an OS upgrade.

Tagging this as release 1.1.2.

Specifically, this affects the python client, making it use the latest
available TLS version supported by both the client and the server.

Currently, the server supports TLS 1.0, 1.1, 1.2 and 1.3 (and no SSL
versions).

This code was originally copied from the Ibis client library which,
when it was written, only supported SSLv3 and TLS 1.0 on the server,
so forcing TLS 1.0 made sense, but things have move on since then.

The historical data used in places in the self tests has changed, so
update those tests accordingly.

Also included the root certificates themselves, and all intermediate
certificates we have ever used, just for reference, and instructions
on how cacerts.txt is constructed (from the root certificates alone).

The new root certificate will be needed by the python and PHP clients
to allow them to connect to the UTBS when its certificates are
renewed, since they will be signed by a new root.

No change needed for Java clients, provided that they are running on
Java 8u91 or later, which ships with this new root certificate.

Also updated the Javadocs to build with Java 1.8.

Tagging this as release 1.1.1.

For API methods that require authentication, be more explicit about the
exact privileges required.

Additionally, in the PHP docs, increased the spacing above the HTTP
method and path that is automatically inserted at the bottom of each
method's docs.

There are 2 new methods. One to get all venues for a particular training
provider, and one to get all venues for all training providers.

There are 2 new methods. One to get all themes for a particular training
provider, and one to get all themes for all training providers.

Additionally:

* Consistently return themes in (title, ID) order across all API
methods.

* Tidy up the documentation for the fetch parameter, making it
consistent across all API methods.

* Fix the script to auto-generate python and PHP client code to account
for the fact that *all* parameters of a method may be optional.

All events returned by the API now return the maximum number of
participants on the events -- an integer (possibly null).

This consists of 3 new methods, one for each of the 3 groups of bookings
as they are presented in the web application -- current bookings,
registrations of interest and training history.

Also added a fetch parameter to the getPerson() method, to make it
consistent with all the other similar API methods. Even though there is
currently no fetchable data for people, one day there might be, so this
makes the API more easily extensible in the future.

These allow self-taught events to be retrieved for programmes, themes
and courses.

This returns programmes from all training providers, unlike the method
from the previous commit, which returns programmes from a single
training provider.

This includes some changes to the client code to support passing pure
dates as well as date-times as input parameters to API methods.

This now tests all the possible values of the fetch parameter, and did
reveal a bug (a typo) in the event -> related courses fetching code on
the server, as well as a bug/typo in the python client code to unflatten
a list of venues.

This allows bookings for multiple events to be retrieved in a single
request.

These don't test creating bookings or people, since there is currently
no way to automate that test, because the database cannot be restored to
its old state.

This will update an existing booking, and optionally create a new
booking if one doesn't already exist for the participant.

TODO: Unit tests for this new method.

This might be for people who should have booked, but just turned up
instead. Or it might be for open events that don't require booking,
where attendance is being recorded. Either way, a booking is required to
record the attendance, and none of the existing booking statuses is
really appropriate, hence this new status: "did not book".

This works across all training providers.

Its constructor now also accepts offsets in hours and/or minutes, and
the documentation now has a more complete python code example.