_**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 request ID reference to `Link`.

<!-- Tell your future self why have you made these changes -->
**Why?**
Request ID can be used to associate links to history event 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**

* Enable section of test that is now supported

* Forgot a change

…577)

<!-- Describe what has changed in this PR -->
**What changed?**
1. Add identity/description to the rules.
2. Add new message with "rule_id, identity, reason" to the PauseInfo

<!-- Tell your future self why have you made these changes -->
**Why?**
Product request - identity/reason should be always populated, for both
manual/rule.

<!-- Are there any breaking changes on binary or code level? -->
**Breaking changes**
Not really. But old "rule_id" in oneof is effectively deprecated.

* Remove cloud files

* Remove cloud from Makefile and proxygenerator

* Support parsing details that aren't anypb.Any type

* PR feedback, simplify code

* Visit response on non-status errors

* PR feedback

* move inbound check

* Stop wrapping status errors in any

* refactor error handling and avoid inline type definitions

* refactor error handling and avoid inline type 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 -->
**What changed?**

Added field `WorkflowExecutionStatus status` to
`StartWorkflowExecutionResponse`.

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

To align Update-with-Start's behavior with a regular Update. A regular
Update returns its outcome from a closed Workflow, to make
Update-with-Start do the same thing, it needs to returns a successful
response in that case. But that would tell the user that a running
Workflow exists. To help the user distinguish whether UwS operated on a
closed or running workflow, this field is introduced.

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

temporalio/temporal#7656

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