Create Turbinia API processor modules

[jleaniz]

Create new processor modules to integrate dftimewolf with Turbinia using Turbinia's new API server.

[jleaniz]

General approach will be to use the turbinia-api-lib library to make API calls to the Turbinia API server and keep dependencies to a minimum.

As a first step, I intend to create new processor modules instead of ripping and replacing the existing ones to provide backwards compatibility for existing clients/users. One idea is to expose a flag in the recipes that use Turbinia modules to indicate whether the new or current/existing client would be used.

This will allow us to easily switch clients if needed. The only drawback is that we willl not be able to immediately removeturbinia or the various GCP packages pinning from the dependencies. That would be possible once we deprecate the current Turbinia client and dftimewolf turbinia processors.

@tomchop thoughts?

[tomchop]

One idea is to expose a flag in the recipes that use Turbinia modules to indicate whether the new or current/existing client would be used.

This wouldn't work, as flags can't really decide which module is used - you'd have to create a module which uses the two clients and choses which one to use depending on the flag (which defeats the purpose of not having to import legacy modules).

At this point I think that we're getting more brekages because of the existence of the legacy turbinia client than what we would get if we decided to migrate everything at once. (see #660) I'd suggest we move forwrad and default to the new Turbinia API for all Turbinia modules.

To preserve backwards compatibility for users who have a working setup with the old turbinia modules, we can rename existing recipes to something like _legacy and keep the old Turbinia modules in the codebase with a deprecation note. Additionally, we can tweak pyproject.toml to add an extras section for the old turbinia modules: https://python-poetry.org/docs/pyproject/#extras