Move microk8s to to setup test-plan and remove install-deps (New)

[motjuste]

Description

This PR moves the installation and setup of microk8s to the setup test-plan originally introduced in PR #1965.

The setup test-plan now includes running the newly added jobs for installing microk8s, enabling addons in it, and exporting its kube-config. These jobs do everything that install-deps script was doing, except that we do not do the unnecessary step of adding the current user to the microk8s group (hence we now need to use sudo in one new place in the test jobs where it was not previously required).

The setup.conf launcher now sets an environment variable that is used by the setup jobs to install microk8s from an appropriate channel. The template launcher setup-def.conf for the Testflinger job and GitHub workflow for DSS regression tests have been similarly updated to setup the correct value for these template parameters from the workflow's input.

The install-deps script is now removed. It's uses in the Testflinger job template job-def.yaml, in the snapcraft.yaml, and in the README have been removed.

Resolved issues

CHECKBOX-1901

Documentation

The README for checkbox-dss snap has been updated. No changes to Checkbox's documentation.

Tests

See execution of this run.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 50.60%. Comparing base (2dab338) to head (b4ce75b).
⚠️ Report is 107 commits behind head on main.

Additional details and impacted files

@@           Coverage Diff           @@
##             main    #1989   +/-   ##
=======================================
  Coverage   50.60%   50.60%           
=======================================
  Files         384      384           
  Lines       41180    41180           
  Branches     7636     7636           
=======================================
  Hits        20841    20841           
  Misses      19594    19594           
  Partials      745      745           

Flag	Coverage Δ
provider-dss	100.00% <ø> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[Hook25]

Consider using the builtin user: directive where appropriate

[motjuste]

Consider using the builtin user: directive where appropriate

I am hesitant about using user: root. For one, it is better to know if the current user does not have the appropriate privileges. Second, I do not want to accidentally do something in some step, e.g. creating a file, that force further steps to also require root. Also, there are some assumptions I can make when I am not root, e.g. that I won't be able to delete the root directory.

Finally, while these changes are not a great example of it, I want uses of sudo to stand out. I don't want to use root to just avoid sudo statements --- uses of root should stand out even higher.