fix(daemon): set TOKIO_WORKER_THREADS to stop tokio trying to read cgroup files which will result in apparmor denials

[sminez]

Addresses the issue reported in canonical/desktop-security-center#71

@olivercalder confirms that this removes the log spam when running in a VM without a desktop session but he's still seeing the following denial which I'm yet to track down:

Oct 10 16:13:26 integration-oracular kernel: audit: type=1400 audit(1728576806.803:30728): apparmor="DENIED" operation="open" class="file" profile="snap-update-ns.prompting-client" name="/proc/417652/maps" pid=417652 comm="5" requested_mask="r" denied_mask="r" fsuid=1000 ouid=0

I've also reduced multiple log lines from INFO to DEBUG so the prompting client is less chatty by default.

[olivercalder]

Looks good, thank you! Is TOKIO_WORKER_THREADS the number of threads in addition to the main thread? And does this still work fine on single-core or dual-core systems?

[sminez]

@olivercalder The docs on how the env var works are found here: it is setting the total number of worker threads which includes the main thread. There is also this which explains the difference between worker threads and blocking threads.

In terms of the current behaviour, we'll be calling into std::thread::available_parallelism which will be erroring due to apparmor blocking the read, leaving us with a single worker thread. So arguably we could (and should?) set this to 1 rather than 2. Setting the count to 2 won't break anything on single core machines but it will result in context switching between the threads with the trade off being that we get an extra thread on multi-core machines. Given that the client runs fine currently I suspect we're probably fine to leave things as they are / swap out the multi-threaded runtime for the single threaded one. (Details of the behaviour are here)

I've always made use of the multi-threaded runtime previously and I'll be honest, I'm not 100% sure if the current-thread runtime is equivalent to the multi-threaded one when the number of worker threads is 1...

[matthew-hagemann]

I see our system requirements for Ubuntu desktop are set as dual core or better, so I think its fair to set worker threads at two to benefit multi-core systems.