version the ioctl interface between opteadm and opte-core

@smklein made a great point on today's CP huddle: during development, as we are integrating different pieces and moving fast, there is a good chance we will come across the scenario where the version of opteadm that is being used by something like Sled Agent will have a different version of the ioctl API than the version the opte-drv kernel module was compiled with (both the commands and their serialization/data format). For example, the semantics of ioctl 5 could change, or the data structure for adding a new firewall rule could have a field added, etc.

Now, opte is a loadable kernel module, and as long as their are no active clients (guest instances), the module can be unloaded and a newer version of opte-drv loaded in its place. However, we still want to explicitly version the API so that we can determine when a given combination of opteadm and opte-drv are incompatible with each other.

I think this should have a few pieces:

• Add an explicit version around the entire API that covers both the available commands and their structures.
• Add an opteadm command/function that returns the API version it expects.
• Add a command to the API itself that returns the version of the API. This is a bit of a chicken-or-egg thing, as we want a command in the API to describe the version so we can know if we can use the API. That is, I'm looking for a command that opteadm can send to opte-drv to determine the API version it presents. One way this could work is that the version command is essentially its own island, and it's always there, and if it ever has to change we keep the entire history of that command on each side (opteadm and opte-drv) so that we know we can always query the version.
• Since I've been terrible at documenting things, make sure to write up a section on whatever design I come up with here so others can know how it's all supposed to fit together.
  • While I'm at it I should also document/viz the overall arch of how the various pieces of opte (opteadm, opte-drv, opte-core) fit together and related to the other pieces of the stack (Sled Agent, viona/bhyve, Propolis, NIC/mac, etc).

Start with the issue’s completed API-versioning item and the remaining opteadm, opte-drv, and opte-core requirements. Define the stable version-query behavior, compatibility checks, and architecture documentation described here. Done means the opteadm query, ioctl version command, and design documentation are complete.