feat(kernel,initrd): extend plugins with new options, stabilize

[dilyn-corner]

This PR extends the behavior of the kernel plugin to include features desired by the Canonical Kernel team. While these options are intended for that specific usage, they are valid options to use in other use-cases.
Their inclusion has expand the complexity of the kernel plugin, so documentation has been improved to try and clarify the most salient choices which impact the decisions snapcrafters should make when crafting a kernel snap. A new spread test has been added (kernel-deb, and the old kernel-deb test has been renamed kernel-bin) to cover this case in a sufficiently comprehensive way.
Comments have been added to the kernel build script to identify the primary patterns of behavior the script will execute.

Test coverage has been expanded to cover the new options.

The initrd plugin's behavior has been modified a bit to improve usability and stability. It should be less fragile now, especially when it comes to cleaning the environment.

The overall behavior and stability of the plugins has been improved.

These changes have been tested by Field and the Kernel team has discussed them (I will not speak for them, we can always ask).
All spread and unit tests pass locally. Docs lint and render well :)

Any behavior-specific changes (like naming the installed kernel image file vmlinuz instead of kernel.img) have been debated internally so all stakeholders are aware of these things; the impact should be minimal as most users are those same stakeholders.

A caveat: with the release of Resolute, a change was made in the location and name of the Resolute release tarball used by the initrd plugin. I have been informed that this is only a short-term divergence and the prior naming convention will be reused at some point. This means that there will be a future PR to fix the initrd plugin once this happens. I have no timelines for this, but I have setup daily tests to check this URL :) This has been resolved.

This PR precedes #6255, which updates the feature branch to HEAD.

The line count is deceptive; the new test adds a whole kernel config file. This alone is over 4k lines.

CC @jicheu @atomcult @kubiko @stewarthore

---

• I've followed the contribution guidelines.
• I've signed the CLA.
• I've successfully run make lint && make test.
• I've added or updated any relevant documentation.
• In documents I changed, I added a meta description if one was missing.
• I've updated the relevant release notes.

[kubiko]

Not that I have approval right, but I tested this with multiple of my custom kernels (build base core24, core26) and it works beautifully
Ship it!

[bepri]

Approving despite the many test failures, because:

• Lint, OSV and integration test failures will be fixed when main is merged into this branch
• Initrd/Kernel spread test failures are flaky, as confirmed by Dilyn via MM
• Other tests are also, rightfully, marked as flaky in the first place.

[medubelko]

@dilyn-corner Glad to see this finally land! Approving pre-emptively. All of my suggestions are about languages quirks.

[medubelko]

Suggested change

	This option is only meaningful when used with ``kernel-ubuntu-debian-package``.
	Requires the ``kernel-ubuntu-debian-package`` key to be set.

[dilyn-corner]

set or true? It's a bool, so setting it is equivalent to key to be 'true', but I'm uncertain of the vernacular you're establishing with your audience.

[medubelko]

Similar to the "non-nil" question from earlier. "is/if set" and "is/if unset" is meant to succinctly communicate "if this key is declared in your project file".

If the key must indeed be true, then it should read something like

Requires the kernel... key to be set to true.

Or:

This key only takes effect if the kernel... key is set to true.

---

Config values are tricky to write about, because they have three states:

• Not assigned by the user, and with no default value
• Not assigned by the user, with a default value (most often true/false, but non-bool and procedural values are also possible)
• Assigned by the user

The result is that asserting any value and asserting no value are important distinctions for the user. In terms of guidance, we need succinct language to communicate a user's inaction (unset) in and action (set).

[dilyn-corner]

That all makes sense. I suppose I took the position of documenting deviations from default behavior, which impacts the phrasing of things like this; kernel-ubuntu-debian-package is an "optional" key, and isn't present in a project file unless the user intentionally adds it; because it's a bool, it couldn't be set to anything else, and so it being "set" is equivalent to it being "True".

I can always be more explicit, though. Indeed, I am explicit about this in other places (line 56, for instance). So I'll change this to match:

Requires the ``kernel-ubuntu-debian-package`` key to be ``true``.

[medubelko]

"real" is a subjective qualifier. Could we be more concrete?

[dilyn-corner]

"real" in this case means something more like "actual" -- what I'm trying to get at is that every other option (well, most) is intended for the intensive case, where one needs to make changes to the options enabled at kernel build time. This route is special, in that you're fine with how the kernel was built, you just want a snap instead. So I think 'actual' captures that?

[medubelko]

What would it mean if we wrote "no changes need to be made" or "the kernel Debian package is intended to be used as-is"?

[dilyn-corner]

I think either option would be equivalent to what I am trying to say; I'll go with the second phrasing.

[mr-cal]

LGTM

[medubelko]

@dilyn-corner @bepri Doc updates look good!

[bepri]

Override-merging for the reasons stated above, these failures are either expected (mostly 'cuz flaky) or will be resolved once main gets merged into the feature branch.