Update storage driver store context metadata

[jmaeagle99]

What was changed

• Remove on StorageDriverStoreContext.serialization_context in favor of a new asymmetric context information system for storage drivers.
• Update S3 driver to use new context information system.

The S3 driver will now generate all keys (assuming context is provided) such that the key will be in the following formats:

v0/ns/{namespace}/wt/{workflow_type}/wi/{workflow_id}/ri/{run_id}/d/sha256/{hash} for all workflow operations, and
v0/ns/{namespace}/at/{activity_type}/ai/{activity_id}/ri/{run_id}/d/sha256/{hash} for standalone activity operations.

The null sentinel value is used for any token which is not known at during the driver store operation. For example, when starting a workflow from a client, the run ID of the worklfow is not known and will have a null value for the {run_id} token.

Key Segments by Operation

Operation	Key segments	Notes
Client: start_workflow	wt=type, wi=ID, ri=null	Run ID not yet assigned
Client: signal_workflow	wt=null, wi=ID, ri=run ID or null	Type not available from client; run ID present if handle was obtained with one
Client: signal_with_start	wt=type, wi=ID, ri=null
Client: execute_update	wt=null, wi=ID, ri=run ID or null	Type not available from client; run ID present if handle was obtained with one
Client: query_workflow	wt=null, wi=ID, ri=run ID or null	Type not available from client; run ID present if handle was obtained with one
Client: schedule action	wt=type, wi=ID, ri=null
Client: async activity (ID reference with workflow ID)	wt=null, wi=workflow ID, ri=run ID or null	Keyed under parent workflow; type not available
Client: async activity (ID reference, no workflow ID)	at=null, ai=activity ID, ri=null	Activity-keyed; type and run ID not available
Client: async activity (task token)	(no context segments)	No identity info in raw token
Workflow worker: schedule activity	wt=type, wi=ID, ri=run ID	Keyed under the scheduling workflow
Workflow worker: start child workflow	wt=type, wi=ID, ri=run ID	Keyed under the parent workflow — payload lives in parent's history
Workflow worker: signal external	wt=type, wi=ID, ri=run ID	Keyed under the sending workflow
Workflow worker: continue-as-new	wt=type, wi=ID, ri=run ID	Keyed under the current run
Workflow worker: result	wt=type, wi=ID, ri=run ID
Activity worker: heartbeat	wt=type, wi=ID, ri=run ID	Keyed under the parent workflow
Activity worker: result	wt=type, wi=ID, ri=run ID	Keyed under the parent workflow

Why?

• Provide more information to storage drivers than what is permissible by SerializationContext
• Create a consistent key format for the S3 driver to better allow external lifecycle management

Checklist

1. How was this tested: Unit and integration tests
2. Any docs updates needed? Yes