Cleanup use of auth tokens

Integration tests of !1294 (closed) fail because of a failed CSRF check. The culprit is here: https://github.com/encode/django-rest-framework/blob/master/rest_framework/authentication.py#L126

If request.user is set, d-r-f assumes that the user is authenticated in the session and therefore requires CSRF checks for POST and PUT. It makes sense: if I'm logged in, I don't want random websites to make me unexpectedly post Debusine API commands.

d-r-f will then set request.user and/or request.auth (see docs) depending on if authentication came from Django or from something else like a token.

What do our API views do at the moment?

Looking at debusine/server/views/work_requests.py, Debusine API code currently checks request.token, which is our own custom extension to request. I suppose we should follow django-request-framework's standard and check request.auth instead.

We also have the view to download artifacts that can accept both user auth and token auth, and it borrows parts from d-r-f. This is what I was trying to cleanup with !1294 (closed).

I would like to tidy up this situation and align to the standards of the frameworks we are using, so I propose to:

• Cancel !1294 (closed)
• Create a Django Request Framework custom authentication class that gets our token into request.auth (!1346 (merged))
• Check request.auth instead of request.token in API views (!1346 (merged))
• Get rid of request.token (!1346 (merged))
• Split debusine.web.views.artifacts.DownloadPathView into a normal view and an API view, or move it to API views and point to that for artifact downloads, or leave it to web/ and make it API accessible (!1348 (merged))