…on timestamps (#585)

_**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?**
- Added two new timestamps to signify when a version first/last receives
traffic in the `WorkerDeploymentVersionInfo` and `WorkerDeploymentInfo`.
Added missing fields from VersionLocalState that were not present in
VersionSummary.

<!-- Tell your future self why have you made these changes -->
**Why?**
- Adding the two new timestamps shall allow operators to have more
visibility into when a version gets activated/deactivated.
- The reason fields from `VersionLocalState` were added to the
`VersionSummary` is because the UI, right now, is querying a bunch of
different places to get information about a specific version. This might
be annoying and the aim of this PR is to make VersionSummary the source
of truth for information related to a specific version. A nice cherry on
top is that this shall also reduce the number of API calls to get
information about a version.

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

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

**What changed?**

- Fix a double semicolon introduced in #579.

**Why?**

- The double semicolon sequence is causing a compilation error in
`protobufjs`, even though this is technically valid according to [the
official Protobuf 3
spec](https://protobuf.dev/reference/protobuf/proto3-spec/#emptystatement).

This is a bug in `protobufjs`, for which there's been [an open issue
ticket](protobufjs/protobuf.js#1322) since
2019, but it was never acknowledged, and a PR fixing this has been
ignored for more than a year.

Given that there's simply no reason to use a double semicolon sequence
anyway, it appears preferable to simply avoid that in our proto
definitions.

_**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 -->
Add a new workflow failure cause for oversized grpc messages

<!-- Tell your future self why have you made these changes -->
We want to be able to distinguish failures with this cause

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

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

**What changed?**
Sync `//Deprecated` comment and `[deprecated = true]` attribute.

**Why?**
When field is deprecated it should be marked with both comment and
attribute to get full support in all languages.

**Breaking changes**
No, only comments/attributes changes.

…istDeployment (#594)

_**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?**
- WISOTT

<!-- Tell your future self why have you made these changes -->
**Why?**
- making more information available in one API call rather than via
multiple API calls.

<!-- 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#7802

_**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 VersionStatus inside `WorkerDeploymentVersionInfo` +
`WorkerDeploymentVersionSummary`

<!-- Tell your future self why have you made these changes -->
**Why?**
- right now, the UI code deduces the status of a version by checking
`CurrentSince`, `RampingSince` and other attributes. This can just be
simplified by adding this enum and the server doing the heavy lifting
instead.

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

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

<!-- Describe what has changed in this PR -->
**What changed?**
Add flags to activity reset/activity update-options requests to support
"restore original options" behaviour.

<!-- Tell your future self why have you made these changes -->
**Why?**
They will help users to "reset" their changes.

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

_**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?**
Add fields to workflow started event to enable inheriting pinned version
and override across CaN when the effective behavior of the WF is pinned.

This inheritance will not happen if the behavior is anything else
(auto-upgrade, pinned-until-continue-as-new, etc)

**Why?**
To differentiate pinned from trampolining

<!-- 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. -->
**Server PR**

_**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?**

Added `TaskQueueStats` field to `DescribeTaskQueueResponse`.

<!-- Tell your future self why have you made these changes -->
**Why?**

To provide non-versioning users with relevant task queue stats.

PS: The long-term plan is to deprecate the ENHANCED mod fields.

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

N/A

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

temporalio/temporal#7816

_**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 -->
add client identity to update-metadata request

<!-- Tell your future self why have you made these changes -->
on the server side we generate a uuid identity. would be nice to allow
user to specify it instead

<!-- 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**

<!-- 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:
temporalio/api#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)