Support custom CDS handlers #74
Description
Some parts of the TxNative class already allow the user to provide their own implementations of various components via dependency injection. The AbstractCache class being a good example of this. It would be good if users could also provide their own implementation of the CDSHandler class.
Users can already point the TxNative class at a different instance of the Transifex CDS via cds_host, and since the code for the CDS is available at https://github.com/transifex/transifex-delivery there's nothing stopping them creating their own CDS (using transifex-delivery as documentation on what endpoints need to be available and how they should behave) and pointing TxNative at this to provide their own implementation at the service level, rather than the application level. However, if your application handles content delivery, then you're forced to either split this out in a separate service (which might be a good thing, but equally might not be), or your application is forced to make requests to itself over localhost (which I really don't want to do - and I can't imagine anyone else would either).
Allowing users to provide their own CDSHandler would provide a lot more flexibility, allowing users to bolt on extra functionality - maybe the source strings are coming from different sources that don't have visibility of one another and you want to check for duplicates to remove wasted effort translating duplicate strings, or maybe you want to run some sort of analysis on the source strings before pushing them to the CDS. Maybe you want to use a local database for content delivery, meaning you don't need to push and pull the translations over HTTP at all. These are just some examples off the top of my head to try to justify the development effort required here.
If this is something that Transifex don't have resource to do, but are happy to adopt it should another contributor carry out the work, then I'm happy to fork and submit a PR for this if I can find some spare time to do so.