Pass along containerd config as return value

[twz123]

Description

• Pass along containerd config as return value
  Return the containerd config as a string instead of having the configurer write it to disk. This reduces the number of struct fields required by the configurer, and makes testing less dependent on the file system.

  Let the containerd component write the file instead.

  Remove the hard-coded string literal for the paths to containerd-cri.toml and use k0s' RunDir instead. This already takes into account the differences between Windows and UNIX-like operating systems, and also takes into account the different defaults when running as non-root user.

  Remove the escapedPath function and inline it directly before the containerd component generates the template.

• Use toml.Marshal to generate default CRI config
  This is more convenient and removes the necessity to declare some one-shot writer variable to get the marshalled data. Moreover, make this a free-standing function, so it's more obvious that the default config is solely dependent on the pause image.

• Simplify hasCRIPluginConfig

  • Use toml.Tree's HasPath function to simplify the check for the CRI plugin config section
  • Make it a free-standing function. The only reason why it had the receiver was to use the usage of the logger.
  • Remove unit tests for it, as all the interesting cases are already covered by the unit tests for handleImports and don't add anything of interest.
  • Add some more comments, refine log statements and error messages.

• Refactor CRI config tests

  • Merge two nearly identical configurer tests
    The two tests "should merge CRI configs" and "should have single import for all CRI configs" were nearly doing the same. One of them was missing two assertions. Combine them into one test.
  • Rename srvconfig import alias to the more idiomatic serverconfig
  • Adjust variable names to more accurately reflect their purpose
  • Transition from require to assert in certain test assertions to continue execution after a failure, allowing for more comprehensive test feedback.
  • Use upper-case CRI instead lower-case cri in descriptive strings

Type of change

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• Documentation update

How Has This Been Tested?

• Manual test
• Auto test added

Checklist:

• My code follows the style guidelines of this project
• My commit messages are signed-off
• I have performed a self-review of my own code
• I have commented my code, particularly in hard-to-understand areas
• I have made corresponding changes to the documentation
• My changes generate no new warnings
• I have added tests that prove my fix is effective or that my feature works
• New and existing unit tests pass locally with my changes
• Any dependent changes have been merged and published in downstream modules
• I have checked my code and corrected any misspellings