I'm creating this draft primarily to get feedback on overall structure and the planned behavior for the plugin API in the PR description. Most of the changes made are just moving code around for easier reuse and setting up the build process, plugin.go is where the bulk of the actual new logic lives

As of right now it's very incomplete and untested - I haven't written golang before, so I'm mostly wanting see if there are any glaring issues so I can make changes sooner rather than later.

One alternate approach to the locking lifecycle would be to have /VolumeDriver.Create only create the dboxed volume but not the volume-mount / lock

Hey @TheGeb. Thanks for creating the first PR in this project :)

I tried to review the PR at least in regard to the structure of the changes. Here are a few things I noticed:

1. I assume the reason for the introduction of the services package is that you want the docker driver to invoke stuff that kind of mirrors what the dboxed CLI already does. Best is to separate these changes from the rest and move them into a new PR, so that I can review and merge them on their own.
2. At the same time, I'm unsure if the docker volume plugin should actually reuse the function from 1.
   Reason is that the steps necessary to implement the API might night necessarily match the way the dboxed CLI was intended to be used. For example, the volume-mount commands are not supposed to create volumes on the API side.
3. You introduced the docker_volume_plugin tag. I wonder why you didn't just use the linux tag? This would also allow you to avoid the extra build artifact.

I remember that we shortly discussed where to put the docker volume plugin code when we first chatted on Reddit. Seeing this code, I now clearly prefer to to have it inside this repo (and not as an external contribution). There is however one thing that needs to be taken care of now: I initially considered having an external plugin that would invoke the dboxed CLI, which has the advantage that a crash inside a volume-mount serve does not bring down the plugin. This is different when we integrate the plugin directly into dboxed and we must find ways to be crash resistent. One way might still be to create separate processes for the serve operation, but we can figure this out later.

@TheGeb I've just created a Discord server that I also plan to use for dev coordination. If you're interested, you can join via the link on dboxed.io