Add support for strong consistency on GetWorkflowHistory and DescribeWorkflowExecution

[c-warren]

What changed?

Adds support to make requests with a QueryConsistencyLevel to:

• GetWorkflowHistory
• DescribeWorkflowExecution

Using STRONG as the QueryConsistencyLevel will direct cadence to retrieve information from the "active" cluster, regardless of where the request is received (active or passive). Note that this will increase the latency of requests that are received in the passive cluster.

The existing methods have been kept for compatibility and can continue to be used.

Why?

Supports the equivalent changes to cadence-frontend.

How did you test it?

Unit tests locally. New integration tests.

Potential risks

---

Detailed Description
[In-depth description of the changes made to the interfaces, specifying new fields, removed fields, or modified data structures]

GetWorkflowHistory and DescribeWorkflowExecution have not been changed.

New methods, GetWorkflowHistoryWithOptions and DescribeWorkflowExecutionWithOptions have been added, mirroring the same payloads sent to the original methods but with an extensible struct passed with the new option QueryConsistencyLevel.

type GetWorkflowHistoryWithOptionsRequest struct {
 	// WorkflowID specifies the workflow to request. Required.
 	WorkflowID string
 	// RunID is an optional field used to identify a specific run of the workflow.
 	// If RunID is not provided the latest run will be used.
 	RunID string
 	// IsLongPoll is an optional field indicating whether to continue polling for new events until the workflow is terminal.
 	// If IsLongPoll is true, the client can continue to iterate on new events that occur after the initial request.
 	// Note that this means the client request will remain open until the workflow is terminal.
 	IsLongPoll bool
 	// FilterType is an optional field used to specify which events to return.
 	// CloseEvent will only return the last event in the workflow history.
 	FilterType s.HistoryEventFilterType
 	// QueryConsistencyLevel is an optional field used to specify the consistency level for the query.
 	// QueryConsistencyLevelStrong will query the currently active cluster for this workflow - at the potential cost of additional latency.
 	// If not set, server will use the default consistency level.
 	QueryConsistencyLevel *s.QueryConsistencyLevel
 }

// GetWorkflowHistoryWithOptions gets history events with additional options including query consistency level.
 // See GetWorkflowHistoryWithOptionsRequest for more information.
 // The errors it can return:
 //   - EntityNotExistsError
 //   - BadRequestError
 //   - InternalServiceError
 func (wc *workflowClient) GetWorkflowHistoryWithOptions(ctx context.Context, request *GetWorkflowHistoryWithOptionsRequest) (HistoryEventIterator, error) {
  ...

The existing methods now call the new ...WithOptions methods, with the QueryConsistencyLevel not populated.

Impact Analysis

• Backward Compatibility: [Analysis of backward compatibility]

The existing methods will behave as they do today, and will not respect the QueryConsistencyLevel query parameter.

• Forward Compatibility: [Analysis of forward compatibility]

The new structs are forwards compatible if no fields are removed (and all fields continue to be respected).

Testing Plan

• Unit Tests: [Do we have unit test covering the change?] Yes
• Persistence Tests: [If the change is related to a data type which is persisted, do we have persistence tests covering the change?] N/A
• Integration Tests: [Do we have integration test covering the change?] Yes
• Compatibility Tests: [Have we done tests to test the backward and forward compatibility?] Integration tests call the existing method(s), as well as the new method(s) against the same cluster.

Rollout Plan

• What is the rollout plan?
• Does the order of deployment matter?
• Is it safe to rollback? Does the order of rollback matter?
• Is there a kill switch to mitigate the impact immediately?