Feature: User-based access to tasks

[mrtamm]

This PR provides the code for associating tasks with the users who create them, and restricting access to tasks based on whether the user is an administrator or the creator of the task. It also supports the scenario when there is no user-authentication: then the tasks have no owners and everyone can see tasks without owners. There are no API-changes due to this development.

Changes to databases should be backward compatible, except that existing tasks (without ownership) won't be visible to non-admin users. In the configuration file, it's now possible to specify that a user (under Basic authentication) is an administrator. It is not supported with OIDC. Related configuration and documentation files were also updated a bit.

For this feature, user authentication information is now stored in the request Context as UserInfo({IsPublic bool, IsAdmin bool, Username string}). Different database implementations get the UserInfo from the Context and evaluate task ownership, or store the username with a task (if Username is not empty).

Notes about database implementations:

1. Badger: tasks are stored under keys tasks<taskId> and their owners under keys owners<taskId>.
2. BoltDB: owners are stored in a separate bucket ("tasks-owner") where taskID (key) has the value of its owner (username).
3. Google Datastore: owner is stored with the task data
4. Amazon DynamoDB: owner is stored with the task data
5. ElasticSearch: owner is stored with the task data
6. MongoDB: owner is stored with the task data

During testing I realised that support for ElasticSearch, MongoDB, Datastore is quite old. For example, I had to use Mongo version 4 (latest is 8) for testing. ElasticSearch client library is at version 5 while ElasticSearch itself is at version 8. The successor of Google Datastore is Google Firestore... I did not go into upgrading but it's good to bear in mind that Badger and BoltDB are probably the most convenient to use, at the moment.

Just in case, here is a reference that the CI pipeline was successful:
https://github.com/mrtamm/funnel-gdi/actions/runs/11291323700

[mrtamm]

My GitHub actions CI script for the second commit succeeded: https://github.com/mrtamm/funnel-gdi/actions/runs/11327029713

[KrKOo]

Shouldn't the RPCClient always use an admin user? Otherwise, it is bound to a single user "account" and cannot access other tasks. If that's the case, it would be nice to mention it in the docs or at least modify the example accordingly.