snapd 2.37.4+18.04 doesn't detect automount/autofs based NFS filesystems

The snapd daemon attempts to determine if NFS filesystems are present using /etc/fstab and the mount list, according to the feature commit added here https://github.com/snapcore/snapd/pull/3958

Unfortunately, in many real-world network login systems, network filesystems are managed by autofs/automount, so that in the case of networking being stalled or servers being down, the boot continues and the local system/users can still be used.

A small example:
/etc/auto.master
---
/home/remoteuser /etc/auto.home
---
/etc/auto.home
---
* -fstype=nfs4,v4.1,rw,nodev,hard,intr,async,noatime,nodiratime,noauto,acl,sloppy,tcp neuralabcss01:/volume1/remotehomes/&
---

What this looks like in mount:
---
/etc/auto.home on /home/remoteuser type autofs (rw,relatime,fd=6,pgrp=1986,timeout=300,minproto=5,maxproto=5,indirect,pipe_ino=36015)
---

Since no NFS filesystem is mounted, snapd starts up and does not enable NFS support:
---
> journalctl -u snapd
Mar 21 10:30:15 neuralabcws01 systemd[1]: Starting Snappy daemon...
Mar 21 10:30:15 neuralabcws01 snapd[1052]: AppArmor status: apparmor is enabled and all features are available
Mar 21 10:30:19 neuralabcws01 snapd[1052]: daemon.go:379: started snapd/2.37.4+18.04 (series 16; classic) neon/18.04 (amd64) linux/4.15.0-46-generic.
Mar 21 10:30:39 neuralabcws01 systemd[1]: Started Snappy daemon.
---

If I then login an NFS user, and restart snapd
---
> journalctl -u snapd
Mar 21 10:33:39 neuralabcws01 systemd[1]: Starting Snappy daemon...
Mar 21 10:33:39 neuralabcws01 snapd[3446]: AppArmor status: apparmor is enabled and all features are available
Mar 21 10:33:39 neuralabcws01 snapd[3446]: backend.go:113: snapd enabled NFS support, additional implicit network permissions granted
Mar 21 10:33:42 neuralabcws01 snapd[3446]: daemon.go:379: started snapd/2.37.4+18.04 (series 16; classic) neon/18.04 (amd64) linux/4.15.0-46-generic.
Mar 21 10:33:43 neuralabcws01 systemd[1]: Started Snappy daemon.
---