This shifts the matching logic out of libpod/container_internal andinto the hook package, where we can reuse it after vendoring intoCRI-O.  It also adds unit tests with almost-complete coverage.  Nowlibpod is even more isolated from the hook internals, which makes itfairly straightforward to bump the hook config file to 1.0.0.  I'vedubbed the old format 0.1.0, although it doesn't specify an explicitversion.  Motivation for some of my changes with 1.0.0:* Add an explicit version field.  This will make any future JSON  structure migrations more straightforward by avoiding the need for  version-guessing heuristics.* Collect the matching properties in a new When sub-structure.  This  makes the root Hook structure easier to understand, because you  don't have to read over all the matching properties when wrapping  your head around Hook.* Replace the old 'hook' and 'arguments' with a direct embedding of  the runtime-spec's hook structure.  This provides access to  additional upstream properties (args[0], env, and timeout) and  avoids the complication of a CRI-O-specific analog structure.* Add a 'when.always' property.  You can usually accomplish this  effect in another way (e.g. when.commands = [".*"]), but having a  boolean explicitly for this use-case makes for easier reading and  writing.* Replace the previous annotations array with an annotations map.  The  0.1.0 approach matched only the values regardless of key, and that  seems unreliable.* Replace 'cmds' with 'when.commands', because while there are a few  ways to abbreviate "commands", there's only one way to write it out  in full ;).  This gives folks one less thing to remember when  writing hook JSON.* Replace the old "inject if any specified condition matches" with  "inject if all specified conditions match".  This allows for more  precise targeting.  Users that need more generous targeting can  recover the previous behavior by creating a separate 1.0.0 hook file  for each specified 0.1.0 condition.I've added doc-compat support for the various pluralizations of the0.1.0 properties.  Previously, the docs and code were not inagreement.  More on this particular facet in [1].I've updated the docs to point out that the annotations being matchedare the OCI config annotations.  This differs from CRI-O, where theannotations used are the Kubernetes-supplied annotations [2,3].  Forexample, io.kubernetes.cri-o.Volumes [4] is part of CRI-O's runtimeconfig annotations [5], but not part of the Kubernetes-suppliedannotations CRI-O uses for matching hooks.The Monitor method supports the CRI-O use-case [6].  podman doesn'tneed it directly, but CRI-O will need it when we vendor this packagethere.I've used nvidia-container-runtime-hook for the annotation examplesbecause Dan mentioned the Nvidia folks as the motivation behindannotation matching.  The environment variables are documented in [7].The 0.1.0 hook config, which does not allow for environment variables,only works because runc currently leaks the host environment into thehooks [8].  I haven't been able to find documentation for their usualannotation trigger or hook-install path, so I'm just guessing there.[1]:cri-o/cri-o#1235[2]:https://github.com/kubernetes-incubator/cri-o/blob/v1.10.0/server/container_create.go#L760[3]:https://github.com/kubernetes-incubator/cri-o/blob/v1.10.0/server/container_create.go#L772[4]:https://github.com/kubernetes-incubator/cri-o/blob/v1.10.0/pkg/annotations/annotations.go#L97-L98[5]:https://github.com/kubernetes-incubator/cri-o/blob/v1.10.0/server/container_create.go#L830-L834[6]:cri-o/cri-o#1345[7]:https://github.com/NVIDIA/nvidia-container-runtime/tree/v1.3.0-1#environment-variables-oci-spec[8]:opencontainers/runc#1738Signed-off-by: W. Trevor King <wking@tremily.us>

This shifts the matching logic out of libpod/container_internal andinto the hook package, where we can reuse it after vendoring intoCRI-O.  It also adds unit tests with almost-complete coverage.  Nowlibpod is even more isolated from the hook internals, which makes itfairly straightforward to bump the hook config file to 1.0.0.  I'vedubbed the old format 0.1.0, although it doesn't specify an explicitversion.  Motivation for some of my changes with 1.0.0:* Add an explicit version field.  This will make any future JSON  structure migrations more straightforward by avoiding the need for  version-guessing heuristics.* Collect the matching properties in a new When sub-structure.  This  makes the root Hook structure easier to understand, because you  don't have to read over all the matching properties when wrapping  your head around Hook.* Replace the old 'hook' and 'arguments' with a direct embedding of  the runtime-spec's hook structure.  This provides access to  additional upstream properties (args[0], env, and timeout) and  avoids the complication of a CRI-O-specific analog structure.* Add a 'when.always' property.  You can usually accomplish this  effect in another way (e.g. when.commands = [".*"]), but having a  boolean explicitly for this use-case makes for easier reading and  writing.* Replace the previous annotations array with an annotations map.  The  0.1.0 approach matched only the values regardless of key, and that  seems unreliable.* Replace 'cmds' with 'when.commands', because while there are a few  ways to abbreviate "commands", there's only one way to write it out  in full ;).  This gives folks one less thing to remember when  writing hook JSON.* Replace the old "inject if any specified condition matches" with  "inject if all specified conditions match".  This allows for more  precise targeting.  Users that need more generous targeting can  recover the previous behavior by creating a separate 1.0.0 hook file  for each specified 0.1.0 condition.I've added doc-compat support for the various pluralizations of the0.1.0 properties.  Previously, the docs and code were not inagreement.  More on this particular facet in [1].I've updated the docs to point out that the annotations being matchedare the OCI config annotations.  This differs from CRI-O, where theannotations used are the Kubernetes-supplied annotations [2,3].  Forexample, io.kubernetes.cri-o.Volumes [4] is part of CRI-O's runtimeconfig annotations [5], but not part of the Kubernetes-suppliedannotations CRI-O uses for matching hooks.The Monitor method supports the CRI-O use-case [6].  podman doesn'tneed it directly, but CRI-O will need it when we vendor this packagethere.I've used nvidia-container-runtime-hook for the annotation examplesbecause Dan mentioned the Nvidia folks as the motivation behindannotation matching.  The environment variables are documented in [7].The 0.1.0 hook config, which does not allow for environment variables,only works because runc currently leaks the host environment into thehooks [8].  I haven't been able to find documentation for their usualannotation trigger or hook-install path, so I'm just guessing there.[1]:cri-o/cri-o#1235[2]:https://github.com/kubernetes-incubator/cri-o/blob/v1.10.0/server/container_create.go#L760[3]:https://github.com/kubernetes-incubator/cri-o/blob/v1.10.0/server/container_create.go#L772[4]:https://github.com/kubernetes-incubator/cri-o/blob/v1.10.0/pkg/annotations/annotations.go#L97-L98[5]:https://github.com/kubernetes-incubator/cri-o/blob/v1.10.0/server/container_create.go#L830-L834[6]:cri-o/cri-o#1345[7]:https://github.com/NVIDIA/nvidia-container-runtime/tree/v1.3.0-1#environment-variables-oci-spec[8]:opencontainers/runc#1738Signed-off-by: W. Trevor King <wking@tremily.us>Closes:#686Approved by: mheon