open-iscsi unconditionally requires ib_iser module which is not built on all Ubuntu kernels

After discussing with Ryan on IRC:

 - the static loading of the modules is bad, and shouldn't be necessary, as it should be possible to figure out at runtime which transports are actually needed by iscsid
 - the current implementation doesn't work in the initramfs at all since the file it creates is only read by systemd
 - upstream's code has support for loading these modules on-demand, *IF* we link against libkmod.

Proposed solution:

 - Build-depend on libkmod-dev
 - Drop the file for loading modules statically
 - Add ib_iser to the list of modules for the initramfs hook, so that iscsi rootfs will work correctly over infiniband as well

Except the upstream build system doesn't actually do anything reasonable wrt libkmod; so instead let's just fall back to letting iscsid modprobe the modules (which it will also do when it needs to).

This bug was fixed in the package open-iscsi - 2.0.874-7.1ubuntu2

---------------
open-iscsi (2.0.874-7.1ubuntu2) eoan; urgency=medium

  * debian/open-iscsi.kmod: drop; no static module list is needed if we let
    iscsid load modules itself. LP: #1833586.
  * debian/extra/initramfs.hook: add ib_iser to the list of modules
    included in the initramfs, so that we can in principle support iscsi
    root on infiniband.

 -- Steve Langasek <email address hidden> Thu, 20 Jun 2019 13:48:46 -0700

Glad to find this discussed and solved already when waking up - thanks Ryan and Steve!

To complete the discussions I'm adding a little reference as on IRC it seemed this question was left open:
"[20:40] <vorlon> rharper: right, I also fundamentally question why the open-iscsi package should hard-code the modules for loading if there's additional configuration required (not necessarily extra packages, but at least non-default config options that should maybe be detected to trigger on-demand module loading)"

I think the history on this is [1] which was converting an old unconditional load (that would do || true, and therefore never make it fail/bad) into something else which instead of the old code had the negative effect that Steve reported here initially.

[1]: https://salsa.debian.org/linux-blocks-team/open-iscsi/commit/592d3d1f6

Looking at this from the perspective of the pi images - should we maybe consider SRUing this down to bionic for the upcoming point-release? Currently it's one of the reasons of running in systemd state degraded in pi's, might be nice to finally have a clean situation. The change looks SRUable. Would there be any negative consequences?

While I do believe the change is PROBABLY safe, I don't think it's particularly justifiable as an SRU. Degraded mode is ugly but aside from masking other bugs, doesn't make a difference at runtime.