CCOR-13193 - run integration(e2e) tests against latest oss conductor + v4 server

[chrishagglund-ship-it]

In this PR:

• oss latest in a small docker stack in the runner
• matrix to test against v4 and v5 for the two sets of integration tests
• fix for missing test fixture
• correct misshapen data structures

regarding the correction of misshapen data structures, it is technically a breaking change, and there is a question then of if this should be bugfix (eg 1.2.1) or major version (2.0.0). I lean towards the "type was impossible/useless" bugfix camp.

Breaking change: WorkflowTask.OnStateChange model corrected to match server contract

What breaks

Conductor.Client.Models.WorkflowTask.OnStateChange changes type:

• Before: Dictionary<string, StateChangeConfig>
• After: Dictionary<string, List<StateChangeEvent>>

Consequences for callers:

• The OnStateChange property and the WorkflowTask(...) constructor's onStateChange
  parameter change type (source-breaking at compile time).
• StateChangeConfig and the StateChangeEventType enum are removed.
• StateChangeEvent moves from the global namespace into Conductor.Client.Models
  (callers now need using Conductor.Client.Models;).

This surfaces on any call that sends or receives a WorkflowDef containing tasks with
onStateChange, e.g. MetadataResourceApi.UpdateWorkflowDefinitions(...)
(PUT /metadata/workflow) and MetadataResourceApi.Get(...) (GET /metadata/workflow/{name}).

Why the old type was wrong

onStateChange is serialized as part of WorkflowDef over the metadata REST API. The
authoritative server model is Map<String, List<StateChangeEvent>>, where the map key is
the event name (onStart, onSuccess, …) and each StateChangeEvent is { type, payload }:

• OSS: conductor/.../common/metadata/workflow/WorkflowTask.java:158 (field),
  StateChangeEvent.java:25-32
• Orkes: orkes-conductor/failover/conductor/.../common/metadata/workflow/WorkflowTask.java:158,
  StateChangeEvent.java:25-32 (identical; Orkes reuses the OSS common model)

There is no StateChangeConfig type anywhere on the server side.

So the server wants:

"onStateChange": { "onStart": [ { "type": "...", "payload": {...} } ] }

The old C# StateChangeConfig produced:

"onStateChange": { "": { "type": ["onStart"], "events": [...] } }

That's wrong on both read and write — wrong key (empty string instead of the event name)
and wrong value shape (a wrapper object with type/events instead of a bare list of
events). It only ever "worked" because nothing round-tripped it against a server that
enforced the shape. The new Dictionary<string, List<StateChangeEvent>> is an exact match
to the server model.

So: bug fix, or breaking change?

Both. The type was never correct, so this is fundamentally a bug fix — but because it
changes a public type, it's source-breaking. Flagging for the team to decide how to ship:

• Major version bump (treat strictly as a breaking change), or
• Minor/patch as a bugfix (argument: the old shape never produced valid requests, so no
  correct code could have depended on it), or
• Gate the new shape behind a feature flag / opt-in if we want a migration window.

[codecov]

Codecov Report

❌ Patch coverage is 72.72727% with 6 lines in your changes missing coverage. Please review.

Files with missing lines	Patch %	Lines
Conductor/Api/EnvironmentResourceApi.cs	40.00%	6 Missing ⚠️

Flag	Coverage Δ
unittests	2.55% <72.72%> (+0.40%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

Files with missing lines	Coverage Δ
Conductor/Client/Models/EnvironmentVariable.cs	100.00% <100.00%> (ø)
Conductor/Client/Models/StateChangeEvent.cs	100.00% <100.00%> (ø)
Conductor/Client/Models/WorkflowTask.cs	19.00% <100.00%> (+19.00%)	⬆️
Conductor/Api/EnvironmentResourceApi.cs	1.34% <40.00%> (+1.34%)	⬆️

... and 1 file with indirect coverage changes

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.