Add TaskListKind Ephemeral

[natemort]

Summary

Add support for Ephemeral TaskLists, which will automatically be deleted once no longer in use. This is behavior already supported by Sticky TaskLists, but non-sticky TaskList scenarios such as sessions and integration tests both require generating dynamic TaskLists. We need similar functionality for these TaskLists.

Requests to Start/SignalWithStart a workflow specify a TaskList instance (Name + Kind), so no changes are needed for those.

Type of Change

• Add new API(s)
• Add new data type(s)
• Add new field(s) to existing data type
• Remove field(s) from data type
• Remove data type(s)
• Remove API(s)
• Other (please provide detailed description)

Data Effect

• Does it change the data stored in database?

Detailed Description

Add new TaskListKind EPHEMERAL.

Add a TaskList to the response of DescribeTaskList so that the server can expose the TaskListKind of a given TaskList. The request currently includes a TaskList, but the TaskListKind is not considered part of the identity of a TaskList and so the Kind field there is ignored. As a result there isn't a way to determine the Kind of a TaskList beyond inferring it from the name or looking at the database.

Add a TaskListKind field to WorkflowExecutionInfo. This allows for DescribeWorkflow to return the TaskListKind the workflow was started with. Currently this is implicitly TaskListKind NORMAL.

Update sqlblobs WorkflowExecutionInfo so that we can store it for SQL persistence types.

Impact Analysis

• Backward Compatibility: Adding new enum types is not backward compatible. Once we have written data with this new type we are unable to rollback. Additionally we need to ensure that clients do not receive this new value before they understand it, as they otherwise will panic. Sessions and our uber-internal integration tests are both host-specific tasklists, which significantly mitigates the risk of this change. The client needs to Start a workflow (or start polling the session tasklist) with TaskListKind EPHEMERAL before it would ever be returned.
• Forward Compatibility: These changes add support for any additional TaskListKinds we may add in the future.

Testing Plan

• Unit Tests: Will be added to Cadence
• Persistence Tests: Will be added to Cadence
• Integration Tests: Will be added to Cadence
• Compatibility Tests: Will be added to Cadence.

Rollout Plan

• What is the rollout plan?
  • Deploy IDL/server changes, along with a client version containing the IDL changes.
  • Wait for it to be deployed fully.
  • Then implement support within the client (behind a flag) to use these values.
• Does the order of deployment matter?
  • Not between Cadence service types, but it does matter between the client and server.
• Is it safe to rollback? Does the order of rollback matter?
  • Once the server has written workflows with this new type we cannot roll back.
• Is there a kill switch to mitigate the impact immediately?
  • No