TRITON-2218 Headnode should support unattended install based on equinix metal metadata

[bahamat]

We've got some custom ipxe scripts for Equinix Metal (née packet.com) that will drop their metadata as a boot module. If a server is booted with the triton installer ipxe script for packet, we'll get the metadata file. If the metadata file exists, we'll generate an answers.json file.

For values needed by answers.json that don't exist in some form in the packet metadata, users can also provide values in the customdata field with the same name. E.g., customdata.root_password. Wherever possible, a suitable default will be used.

This should allow for unattended install.

[bahamat]

@danmcd You make a good point about the boot module stuff. It's not well documented. There's @jlevon's blog for loader and @wesolows' blog for grub, and there's a very little bit in smartos-docs, but boot modules with PXE is very under-documented (which is putting it mildly), and there are some severe limitations with iPXE (OS-3770, which we fixed, but upstream doesn't want to take because it would render some other operating systems unbootable. Speaking of which, our best workaround for that would be to chainload our own ipxe binary after Packet's).

[bahamat]

I've now got this fully working. Some notes:

• I had to change the ipxe script because ipxe has a 440B limit that it can pass to the kernel. Without it, the tinkerbell metadata boot module was getting truncated and would not load.
• Because of the ipxe limit I did the following:
  • eliminated the test ping (just use curl, and report the curl error code)
  • In the ipxe tar, symlink fulliso.tgz to the real file
  • In the installer, assume the name fulliso.tgz as relative to the boot-file path from bootparams
  • I'm also inclined to remove the iso name from the ipxe file. I don't think we need it anymore, but we can leave the mechanism in the installer which could help for dev/debugging later by giving us the ability to pass in an arbitrary name