[bug#45403] [PATCH] gnu: zfs: Split into packages specific for each of our major supported kernel versions.

[raid5atemyhomework]

This doesn't work, for two reasons:

* The kernel-module is in the output "module" of the `zfs` package.  The code 
specifically checks for `(package? module)`, but we have to specify it as 
`(list system-zfs "module")`.
* ZFS is primarily managed via userspace tools, that's what ZFS users know how 
to use, and we should support that so that Guix users can ask non-Guix ZFS 
users for help with their ZFS problems.  The userspace tools are included in 
the package.  If the base `zfs` package cannot compile because it's 
incompatible with the default kernel, then the userspace tools are nonexistent 
and there is no way to manage ZFS.
  * So, for example we can't just remove the "module" output and have the `.ko` 
installed in the default "out" output, our core problem is we need to compile a 
ZFS module ***and*** userspace tools.
  * We can try to split the compilation to separate the ZFS module from the 
userspace tool, but that risks brittleness and subtle incompatibilities between 
a ZFS module compiled for your local kernel (which cannot be the latest and 
greatest kernel since the kernel does not maintain interface compatibility with 
kernel modules and the ZFS module is always having to catch up), and ZFS 
userspace tool compiled for the default latest-and-greatest kernel (even if we 
somehow manage to compile ***just*** the userspace tools with the latest 
kernel, there may be implicit assumptions about kernel constants and so on 
passed from the userspace tools to the kernel module, which may cause problems 
and birttleness).

So it's just safer to always override the `zfs` `#:linux` with the system 
kernel, and install it in `(packages ...)` and in `(kernel-loadable-modules 
...)`.

* We get compileability as long as older kernel is used.
* We ensure that the userspace tool is built for the same kernel module for a 
compatible kernel, at all generations of the `guix system`.

Thanks
raid5atemyhomework

> Why is this needed? KERNEL-LOADABLE-MODULES are already automatically
> adapted in this way.
>
> See this in gnu/system.scm :
>
> (define* (operating-system-directory-base-entries os)
> "Return the basic entries of the 'system' directory of OS for use as the
> value of the SYSTEM-SERVICE-TYPE service."
> (let* ((locale (operating-system-locale-directory os))
> (kernel (operating-system-kernel os))
> (hurd (operating-system-hurd os))
> (modules (operating-system-kernel-loadable-modules os))
> (kernel (if hurd
> kernel
> (profile
> (content (packages->manifest
>
>                                  (cons kernel
>                                        (map (lambda (module)
>                                               (if (package? module)
>                                                   (package-for-kernel kernel  
>   <-----
>                                                                       module)
>                                                   module))
>                                             modules))))
>                        (hooks (list linux-module-database)))))
>          (initrd  (and (not hurd) (operating-system-initrd-file os)))
>          (params  (operating-system-boot-parameters-file os)))
>     `(("kernel" ,kernel)
>       ,@(if hurd `(("hurd" ,hurd)) '())
>       ("parameters" ,params)
>       ,@(if initrd `(("initrd" ,initrd)) '())
>       ("locale" ,locale))))   ;used by libc