Added docs for workflow versioning

[acroca]

At the moment I just added the Go code, as it's the only SDK that supports it. We'll need to add more code examples as we add support.

[JoshVanL]

Why is the change non deterministic?

[acroca]

Rephrased. I meant that the changes would be non-deterministic if we didn't have this versioning scheme.

[WhitWaldo]

I've got a few comments (mostly suggestion for rephrasing) as well

[WhitWaldo]

While workflows can certainly run for a long period of time, I'd suggest highlighting this as one of several scenarios instead of articulating it as the only one. Also likely is that workflows are running and mid-flight when an application upgrade is deployed, requiring versioning.

[acroca]

Rephrased, what do you think now?

[WhitWaldo]

Duplicate patch checks should stall too as it suggests that the check may have moved between replays as well.

[acroca]

It's possible to check the same patch multiple times, as long as the final list of evaluated patches remains consistent across reruns. So, for example, the list can potentially be "patch1", "patch2", "patch2", "patch3"

[WhitWaldo]

Sure, but also the order of the patches, right? This is what I was asking about whether the patches need to be reported as standalone events instead of metadata on the event is that the standalone events would allow us to infer the order in which patches are applied between other events. By just building a list of all the patches observed from the event source, shouldn't we infer that a patch is called out of order (even if just duplicated) if we see a list of "patch1", "patch2", "patch3" and then an ask comes in for "patch1" even though it's already been evaluated and in the event history?