Add attributes needed by server to propagate nexus tasks to worker

[rkannan82]

What changed?

Added worker_control_task_queue to poll requests:

• PollActivityTaskQueueRequest
• PollWorkflowTaskQueueRequest
  Note: worker_instance_key was already added to these requests in Enhance ShutdownWorkerRequest and poll calls with worker_instance_key #686.

Added worker_instance_key and worker_control_task_queue to:

• RespondWorkflowTaskCompletedRequest: This API is used to eagerly fetch activity.

Why?
To enable server to send nexus tasks to worker.
Example use case:

• User cancels a workflow.
• Server sends activity cancellation tasks to all workers that could be processing activities belonging to the workflow.

Breaking changes: None
Server PR

[cretz]

No big blockers, though I noticed the "Server PR" section of the PR template was removed from the description of this PR. I do think we should wait for most of server impl to understand this has everything needed (no use merging before then).

[cretz]

LGTM, but mentioned in last review, the "Server PR" section removed from description template, would like to see implementation get a bit further and linked if possible

[rkannan82]

No big blockers, though I noticed the "Server PR" section of the PR template was removed from the description of this PR. I do think we should wait for most of server impl to understand this has everything needed (no use merging before then).

Chad, How can I make progress on the server PRs without submitting this API change? I might have asked this before, but what is the recommended protocol? Should I have started the server PRs in my own repo (forked) and have that reference this unsubmitted

LGTM, but mentioned in last review, the "Server PR" section removed from description template, would like to see implementation get a bit further and linked if possible

I added the server PR to the description. temporalio/temporal#9231

[cretz]

Should I have started the server PRs in my own repo (forked) and have that reference this unsubmitted

Yeah, basically this. It just means you have a PR mostly done but referencing your API branch instead of API master. It's just a good way to make sure we don't "oh yeah" during implementation (even when we think we're so sure what we want from he API). May be able to ask server peers on common approach here, e.g. feature branches.