When snap refresh.hold is set to forever, an admin is saying they do
not want generic automated refreshes of snaps performed by default.

This should be an indicator to cloud-init to avoid calling snap refresh
on such systems due to a `package_upgrade: true` present in user-data.

For network-limited environments with images which have the snap package
manager but don't want to wait and timeout on snap refresh, the following
user-data can be provided to still allow for package_upgrade: true,
and avoid a 20-30 second wait on snaps being unable to access certain
snap URLs.

   #cloud-config
   package_upgrade: true
   snap:
     commands:
       00: snap refresh --hold=forever

cloud-init now interrogates the state refresh.hold value by calling
  snap get system -d

If snap refresh --hold was called in that environment to set 'forever',
cloud-init will skip calling refresh and log the reason for skipping.

We cannot honor short time-based refresh.holds because the snap
services place a short hold in early boot anyway as systemd units
startup.

Fixes: canonicalGH-5290