Pass real WorkflowId for full replay exposed to users in Worker#replayWorkflowExecution

[Spikhalskiy]

Actual Behavior

Currently during a full replay that is explicitly exposed to users using Worker#replayWorkflowExecution, JavaSDK supplies fake WorkflowId which can break determinism if workflow code depends on these values.

Expected Behavior

Actual values from the history should be taken and supplied to the Workflow in WorkflowInfo during replay.

Additional context

https://community.temporal.io/t/recommended-approach-to-testing-backwards-compatibility/5511

Good catch from Max that the same shouldn't apply to RunID, because usage of runId in workflow code is non-deterministic (think of reset)

[mfateev]

The workflow code must not depend on runId as reset operation changes it.

[Spikhalskiy]

@mfateev Fair, good catch on runId. I will add this comment on WorkflowInfo#getRunId javadoc, because I don't think we state this unobvious fact anywhere.

[bergundy]

We should consider putting run_id in unsafe (might be too late though), the only issue is that the current run_id isn't stored in history so we can't provide it to the replayer, we only have original_run_id in WorkflowExecutionStarted which is the closest thing.

[mfateev]

There is originalRunId that is preserved on reset.

[Spikhalskiy]

Addressed by #1497