The short version was:
1, determine your swap with 'fdisk -l'
2, do mkswap on your swap partition - RECORD THE UUID WHICH THIS COMMAND OUTPUTS
3, now use this UUID to put into fstab and resume files...RESUME=UUID=<the-swap-partition-uuid-from-vol_ID>
should go in /etc/initramfs-tools/conf.d/resume
4, update-initramfs -u
5, reboot normally after this finishes
What caused my problem in the first place is still very much a mystery though.
Reading through the threads, it appears that the general idea is that either the hibernate or the suspend failed for an unknown reason. This left the hibernation image stored in the swap space, which can apparently cause the swap space to be considered corrupted, and therefore not be mounted.
However, most of the comments indicate that in this scenario the UUID issues, which are what the above steps fix, only appear once the user has manually run mkswap, which changes the UUID of the swap partition. If, as Ubuntu defaults to doing, you are mounting partitions by UUID, and not just label, then once changed, mounting cannot succeed until the fstab is updated, manually.
However, in my case, I was already getting UUID errors when running
swapon -va, which was why I began tracking down the problem in the first place. I certainly didn't run mkswap before the error appeared, so why did either a) the UUID change, or b) the symlink for the UUID disappear? That is half the mystery, and what caused the hibernate to begin failing is the other half.
However, for now it is functioning fine, so I probably won't be spending much time digging further into it, unless I have more problems with it in the future,