We plan to implement an automated file indexing in the future.

Right now (after #434), there is a database object representing indexed files, but there's no way to manipulate them - add files, remove them, etc.

In this issue I propose to add three endpoints to mquery:

POST /api/queue/{ursadb_id}

Takes a JSON body with a list of file paths on the ursadb server to be indexed.

For example, POST to /api/queue/default with ["/mnt/samples/12345"] will tell ursadb with ID default that a file /mnt/samples/12345 should be indexed.

This endpoint should support all QueuedFile fields, i.e. tags and index types, etc.

JSON body can look like this:

[
    { "path": "...", "types": [...], "tags": [...] },
    { "path": "...", "types": [...], "tags": [...] },
]

or:

{
    "paths": ["..."],
    "types": [...],
    "tags": [...] 
]

whichever is easier to implement.

GET /api/queue/{ursadb_id}

Returns a JSON with enough information to show the queue status in the admin panel. Probably for now this should be just something like:

[
    {
        "ursadb_id": "default",
        "size": 1330
        # I can't think of anything more useful - maybe date of oldest and newest file?
    },
    ...
]

POST /api/queue/{ursadb_id}/clear

Or just DELETE /api/queue/{name} if you're feeling RESTy - to be decided by implementer.
Takes no parameters, and removes all files from the specified queue (i.e. removes all QueuedFiles with the given ursadb_id from the database).

Finally, all endpoints must be hidden behind appropriate permissions. We need two new user roles: can_view_queues and can_manage_queues. I think every user should be able to see queue status, and admin should be able to manage them by default. Add the permissions to the groups by default (see expand_role function).

This should most likely be implemented more than one PR, to avoid one huge PR