The current policy plugin system assumes that the target plugin
uses our opinionated Node.js loader shim to set up the plugin. This
makes it impossible to leverage plugins written in other languages
(like [Python](pulumi/pulumi-policy#98) or, in my case, Go).
It turns out this shim isn't entirely required. It's actually just
there for convenience, as it hides the boilerplate of implementing
the gRPC analyzer server necessary to communicate with the engine.
If you've implemented said interface by hand, or via some alternative
mechanism, there's no reason we can't just load the plugin like we
do with other plugins -- languages, resource providers, etc.
This change is arguably a bit of a hack. It looks at the target
--policy-pack and, if it's a directory, keeps the old behavior of
using the Node.js shim. If it's a file, on the other hand, it assumes
that file is the plugin binary and loads it directly. I'm not actually
suggesting this is the right way to do it. But it does unblock the
project I'm currently tinkering with.
This also calls into question what approach we'd actually want to
take with service-managed policy packs.
Either way, we will need to figure out what approach to take that
supports authoring policy packs in different languages.
8b9645e79e