Add orchestration versioning support

[andystaples]

Adds orchestration versioning support

Syntax:

To add a versioning strategy to the worker:

    with DurableTaskSchedulerWorker(host_address=endpoint, secure_channel=True,
                                    taskhub=taskhub_name, token_credential=None) as w:
        w.add_orchestrator(single_activity)
        w.add_activity(plus_one)
        w.use_versioning(worker.VersioningOptions(
            version="1.0.0",
            default_version="1.0.0",
            match_strategy=worker.VersionMatchStrategy.CURRENT_OR_OLDER,
            failure_strategy=worker.VersionFailureStrategy.FAIL
        ))
        w.start()

To add a default version to the client (version to use when scheduling new orchestrations):

        task_hub_client = client.TaskHubGrpcClient(default_version="1.0.0")

To schedule an orchestration with a manual version:

        id = task_hub_client.schedule_new_orchestration(sequence, input=1, version="1.0.0")

To schedule a sub-orchestration with a manual version:

        yield ctx.call_sub_orchestrator(sequence_suborchestator, input=1, version='1.0.0')

[andystaples]

Notes to self:

[andystaples]

I'm not super happy with this small file or propagating information using exceptions like I'm doing. Open to better solutions

[berndverst]

The PR looks good. The one thing I am wondering about:
Am I able to actually provide two versions of my orchestration that live side by side (say 1.2.0 and 1.2.2) and route to the correct version according to either the version I requested or my policies?
I don't see any tests covering this and it's not clear to me whether / how this is possible.

[andystaples]

The PR looks good. The one thing I am wondering about: Am I able to actually provide two versions of my orchestration that live side by side (say 1.2.0 and 1.2.2) and route to the correct version according to either the version I requested or my policies? I don't see any tests covering this and it's not clear to me whether / how this is possible.

Short answer... not really
Long answer: The logic that picks up items from the task hub and distributes them to Durable workers for processing isn't version-aware. It simply finds the next available worker and assigns it the oldest item that still needs processing from the task hub. So, if you have two orchestrations, 1.2.0 and 1.2.2, and two workers with the corresponding versions, it is pseudo-random which worker will process what. That's why we offer VersionFailureStrategy.REJECT, so that if a work item goes to a worker not capable of processing it, you can keep reprocessing it until hopefully it gets assigned to a valid worker
The feature is definitely not designed to have multiple versions of the same app running at the same time for long periods of time, though. You'd want separate task hubs for that. It's more for the short-term during high availability deployments

[berndverst]

Per off GitHub discussion this looks good.