update-motd-fsck-at-reboot: exclude nbd devices

[Impact]

* update-motd-fsck-at-reboot will block shutdown if a broken NBD device is present in the system when it executes. In some configurations (e.g. when sudo authorisation is provided via sssd, which stops before this task completes), this can result in a hard power cycle being required to return a machine to service.

* Users with NBD devices will erroneously see them reported as devices that will be fsck'd at next boot.

[Test Plan]

* Get a QEMU image containing an ext4 partition (e.g. https://cloud-images.ubuntu.com/releases/focal/release/ubuntu-20.04-server-cloudimg-amd64.img)
* `qemu-nbd -c /dev/nbd0 <that image>`
* `mount /dev/nbd0p2 /mnt` (partition number may vary depending on your image)
* Execute `update-motd-fsck-at-reboot`
* Observe NBD device not included

[Where problems could occur]

If the one-line fix is incorrect, users may not receive notification of fsck'ing that is going to happen, which they may rely on.

[Original Report]

I've ended up in a situation where a machine's /dev/nbd* devices are in a broken state: the easiest way for me to fix this is to reboot the system. However, the reboot is blocked by update-motd-fsck-at-reboot trying to run dumpe2fs against one of the broken partitions:

$ ps faux
...
root 191396 0.0 0.2 37864 8672 ? Ss 12:37 0:00 sshd: dwatkins [priv]
root 191421 0.0 0.0 2608 480 ? S 12:37 0:00 \_ sh -c /usr/bin/env -i PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin run-parts --ls
root 191422 0.0 0.0 2496 508 ? S 12:37 0:00 \_ run-parts --lsbsysinit /etc/update-motd.d
root 191455 0.0 0.0 2608 1748 ? S 12:37 0:00 \_ /bin/sh /usr/lib/update-notifier/update-motd-fsck-at-reboot
root 191483 0.0 0.0 3480 944 ? D 12:37 0:00 \_ dumpe2fs -h /dev/nbd0p2
...

These NBD devices will not be present after a reboot, so I think the script would probably be more correct if it omitted operating on these devices.