add `ManagerIdentity` field to WorkerDeployment, and API to set/unset (…

…#632)

_**READ BEFORE MERGING:** All PRs require approval by both Server AND
SDK teams before merging! This is why the number of required approvals
is "2" and not "1"--two reviewers from the same team is NOT sufficient.
If your PR is not approved by someone in BOTH teams, it may be summarily
reverted._



<!-- Tell your future self why have you made these changes -->
I want the Worker Controller to stop making changes to a Worker
Deployment if it detects that another client has written to the same
Worker Deployment. This is so that, if a user calls `SetCurrentVersion`
or `SetRampingVersion` from the CLI during an incident, the Controller
does not overwrite that change.

`LastModifiedBy` is not enough for this feature, because we need a way
for the "other client" (likely user CLI in most cases, maybe UI if we
allow such changes through the UI some day) to indicate to the
controller that manual changes are no longer needed and the controller
can safely take ownership over writing to this Worker Deployment again.

I thought about doing this via a `Metadata` on the Deployment, similar
to WorkerDeploymentVersion Metadata, but I can't think of any other use
cases for Deployment-level metadata, and I think this is load-bearing
enough to deserve it's own field, where we can clearly document
semantics.


<!-- Are there any breaking changes on binary or code level? -->
No


<!-- If this breaks the Server, please provide the Server PR to merge
right after this PR was merged. -->
Not implemented in server yet because this is just a proposal

bug: add timestamp to TriggerImmediatelyRequest (#606)

_**READ BEFORE MERGING:** All PRs require approval by both Server AND
SDK teams before merging! This is why the number of required approvals
is "2" and not "1"--two reviewers from the same team is NOT sufficient.
If your PR is not approved by someone in BOTH teams, it may be summarily
reverted._

<!-- Describe what has changed in this PR -->
**What changed?**
adding a timestamp to `TriggerImmediatelyRequest` message

<!-- Tell your future self why have you made these changes -->
We can make the wft “more idempotent”: put the desired trigger time in
the trigger immediately request itself, so it goes in the signal
payload, so all wfts attempt to start the target with the same id.


<!-- Are there any breaking changes on binary or code level? -->
**Breaking changes**


<!-- If this breaks the Server, please provide the Server PR to merge
right after this PR was merged. -->
[**Server PR**](temporalio/temporal#7968)

Add DescribeWorker API (#624)

<!-- Describe what has changed in this PR -->
**What changed?**
Add DescribeWorker API.
Extracted from [this PR](#622). 

<!-- Tell your future self why have you made these changes -->
DescribeWorker - will be needed to get all the heartbeat information
from the worker.
Partially this can be covered by "ListWorkers" with query
"WorkerInstanceKey = 'xxx'", but this is a dedicated API that doesn't
require query processing.

Extracting into separate PR so that one is concentrated on worker
payload only.

<!-- Are there any breaking changes on binary or code level? -->
**Breaking changes**
Introduce new API

<!-- If this breaks the Server, please provide the Server PR to merge
right after this PR was merged. -->
[Server PR](temporalio/temporal#8094)

Add plugin info to worker heartbeats (#619)

Add worker visibility API - RecordWorkerHeartbeat and ListWorkers (#601)

<!-- Describe what has changed in this PR -->
**What changed?**
What changed?
* 2 new APIs added:
   * WorkerHeartbeat
   * ListWorkerStatus
* WorkerInfo information added to:
   * ShutDownWorker request
   * Poll(Activity|Nexus|Workflow)TaskQueue requests
   
This is "for merge".
Here is a previous PR, where we discuss this at length:
#599

<!-- Tell your future self why have you made these changes -->
**Why?**
Part of the worker visibility work. Workers should be able to report
their status.
Users should be able to get information about workers.

<!-- Are there any breaking changes on binary or code level? -->
**Breaking changes**
Yes - new API is introduce.

<!-- If this breaks the Server, please provide the Server PR to merge
right after this PR was merged. -->
**Server PR**
[Server PR](temporalio/temporal#7870)

change Version to struct, prevent misconfiguration of VersioningOverr…

…ide (#579)

_**READ BEFORE MERGING:** All PRs require approval by both Server AND
SDK teams before merging! This is why the number of required approvals
is "2" and not "1"--two reviewers from the same team is NOT sufficient.
If your PR is not approved by someone in BOTH teams, it may be summarily
reverted._

What changed?
- Make override a one of and add different pinned override types.
- Change version from string to struct
- Make nil Version represent "send tasks away from versioned workers and
to unversioned workers"


Why?
- To prevent misconfiguration and to expand the override definition to
accommodate the new PinnedUntilContinueAsNew behaviors.
- Using a string to represent structured data, whose subfields
frequently need to be considered separately, is brittle and not good for
anyone using it. Struct is better.
- "unversioned version" is contradictory, and nil is a nice way to
represent that the versioning story of a task queue is no longer in the
control of the Deployment whose `RoutingConfig` you are reading.


<!-- Are there any breaking changes on binary or code level? -->
Variables are being deprecated, but the content of the code is not
changing.
The idea of "Unset Ramp" having a separate meaning from "0% Ramp" is
removed. 0% ramp now is the only way to have "no ramp" / 100% of traffic
going to Current Version. Nil `ramping_deployment_version` + non-zero
`ramping_version_percentage` is the way to ramp traffic to unversioned
workers.

The SDK interface for this could look like:
```
deployment := client.GetHandle(deploymentName)

// set current to a version
deployment.SetCurrentVersion(buildId) -> current set to deploymentName/buildId
deployment.UnsetCurrentVersion() -> current set to nil

// set current to unversioned
deployment.UnsetCurrentVersion() -> current set to nil


deployment.SetRampingVersion(buildId, 50) -> ramp set to (deploymentName/buildId, 50)
deployment.UnsetRampingVersion() -> ramp set to (nil, 0%)
deployment.RampToUnversioned(50) -> set to (nil, 50%)
```


<!-- If this breaks the Server, please provide the Server PR to merge
right after this PR was merged. -->
**Server PR**

---------

Co-authored-by: Spencer Judge <spencer@temporal.io>
Co-authored-by: Shahab Tajik <shahab@temporal.io>

Add link field to Callback (#576)

_**READ BEFORE MERGING:** All PRs require approval by both Server AND
SDK teams before merging! This is why the number of required approvals
is "2" and not "1"--two reviewers from the same team is NOT sufficient.
If your PR is not approved by someone in BOTH teams, it may be summarily
reverted._

<!-- Describe what has changed in this PR -->
**What changed?**
Add `links` field to `Callback`.

<!-- Tell your future self why have you made these changes -->
**Why?**
Be able to explicitly associate a callback with links.

<!-- Are there any breaking changes on binary or code level? -->
**Breaking changes**


<!-- If this breaks the Server, please provide the Server PR to merge
right after this PR was merged. -->
**Server PR**

Add ApplicationErrorCategory to ApplicationFailureInfo (#570)

<!-- Describe what has changed in this PR -->
**What changed?**
Added an ENUM `ApplicationErrorCategory`, used in
`ApplicationFailureInfo` proto.

<!-- Tell your future self why have you made these changes -->
**Why?**
Give users a way to categorize application failures. Error categories
map to different observability behaviours SDK-side (i.e.
logging/metrics), part of the work for benign exceptions. Categories
could also be used with rules in the future.

<!-- Are there any breaking changes on binary or code level? -->
**Breaking changes**
No

<!-- If this breaks the Server, please provide the Server PR to merge
right after this PR was merged. -->
**Server PR**
Don't believe this breaks server or requires any changes to server

Add more state to the pending activity state (#565)

_**READ BEFORE MERGING:** All PRs require approval by both Server AND
SDK teams before merging! This is why the number of required approvals
is "2" and not "1"--two reviewers from the same team is NOT sufficient.
If your PR is not approved by someone in BOTH teams, it may be summarily
reverted._

<!-- Describe what has changed in this PR -->
**What changed?**
Add PAUSED/PAUSE_REQUESTED states to the PendictActivityState enum.

<!-- Tell your future self why have you made these changes -->
**Why?**
To easily differentiate between "activity is paused on server and still
running on worker" and "activity is paused on server and not running on
worker". This is the result of our discussion for activity commands.

In old terms:
"state == PAUSED" is "state = SCHEDULLED and paused_flag = true"
"state == PAUSE_REQUESTED" is "state = STARTED and paused_flag = true"

Add ResourceExhaustedCause for namespace operations (#562)

**What changed?**
Added a new ResourceExhaustedCause
RESOURCE_EXHAUSTED_CAUSE_OPERATIONS_RATE_LIMIT.

**Why?**
We are introducing a new namespace operations rate limit which can
throttle frontendRPS, poll requests and history tasks. That rate limiter
will return this cause.

**Breaking changes**
No