…rrectly (#33706)

### Issue # (if applicable)

Closes #33707

### Reason for this change



If a stack with name 'some-stack' includes an info annotation

```ts
Annotations.of(this).addInfo(`stackId: ${this.stackId}`);
```

then the following output results:

```
[Info at /some-stack] [object Object]
```

That's because data comes from Annotations and the data can be of object type containing 'Fn::Join' or 'Ref' when tokens are included in Annotations.

The issue mentioned a proposal to output the data in the form of tokens like `[Info at /CdkSampleStack] ${Token[AWS::StackId.1116]}`.

### Description of changes



**Approach 1** for now. (I am still wondering if approach 3 would be better...)

See below:

### Approach 1

The PR makes messages with tokens by annotations unresolved.

#### NOTE

This change would also output a token format in `manifest.json`.

**If users run integ tests with annotations including tokens, the manifest.json would change for every run.** (like `${Token[AWS::StackId.1119]}` -> `${Token[AWS::StackId.123]}` -> `${Token[AWS::StackId.521]}` -> ...)

```json
{
  // ...
  "CdkSampleStack": {
    // ...
      "metadata": {
        "/CdkSampleStack": [
          {
            "type": "aws:cdk:info",
            "data": "stackId: ${Token[AWS::StackId.1119]}",
```

### Approach 2

Change the type for the `msg.entry.data` (`MetadataEntryData` for `MetadataEntry`) to a string type with `JSON.stringify` if the type is an objective type in cdk-cli.

https://github.com/aws/aws-cdk-cli/blob/cdk%40v2.1003.0/packages/%40aws-cdk/toolkit-lib/lib/toolkit/toolkit.ts#L771

Then I had submitted the [PR](aws/aws-cdk-cli#101) in aws-cdk-cli.

But talked with Rico that the change should be made inside cdk-lib and leave the token unrendered.

aws/aws-cdk-cli#101 (comment)

### Approach 3

Change the data type to a string type after resolve if the data is by annotations with tokens.

This approach doesn't make differences in manifest.json for every run and the original format (with 'Ref' or 'Fn::Join') is kept.

However, the issue for this PR and comments in the PR submitted (aws-cdk-cli) has proposed the approach with unresolved tokens, I decided the approach 1 for now.

63fd78b

```ts
    if (node.node.metadata.length > 0) {
      // Make the path absolute
      output[Node.PATH_SEP + node.node.path] = node.node.metadata.map(md => {
        const resolved = stack.resolve(md) as cxschema.MetadataEntry;

        const isAnnotation = [
          cxschema.ArtifactMetadataEntryType.ERROR,
          cxschema.ArtifactMetadataEntryType.WARN,
          cxschema.ArtifactMetadataEntryType.INFO,
        ].includes(md.type as cxschema.ArtifactMetadataEntryType);

        // Transform the data to a string for the case where Annotations include a token.
        // Otherwise, the message is resolved and output as `[object Object]` after synth
        // because the message will be object type using 'Ref' or 'Fn::Join'.
        const mdWithStringData: cxschema.MetadataEntry = {
          ...resolved,
          data: (isAnnotation && typeof resolved.data === 'object') ? JSON.stringify(resolved.data) : resolved.data,
        };
        return mdWithStringData;
      });
    }
```

This approach outputs the message as the following style:

```
{"Fn::Join":["",["Cannot add a resource policy to your dead letter queue associated with rule ",{"Ref":"Rule4C995B7F"}," because the queue is in a different account. You must add the resource policy manually to the dead letter queue in account 444455556666. [ack: @aws-cdk/aws-events-targets:manuallyAddDLQResourcePolicy]"]]}
```

### Additional Information

see: 

#33707 (comment)

aws/aws-cdk-cli#101 (comment)

### Describe any new or updated permissions being added




### Description of how you validated changes



Unit tests.

### Checklist
- [x] My code adheres to the [CONTRIBUTING GUIDE](https://github.com/aws/aws-cdk/blob/main/CONTRIBUTING.md) and [DESIGN GUIDELINES](https://github.com/aws/aws-cdk/blob/main/docs/DESIGN_GUIDELINES.md)

----

*By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*

…33752)

### Issue #33751

Closes #33751.

### Reason for this change

The conditional workflow trigger (`addconditionalTrigger`) in the `aws-glue-alpha` package contains inconsistent casing and should be updated to camel case.

### Description of changes

Updated the conditional workflow trigger (`addconditionalTrigger`) to camel case (`addConditionalTrigger`).

### Describe any new or updated permissions being added

None.

### Description of how you validated changes

Updated existing unit and integration tests, `aws-glue-alpha/test/integ.workflow.ts` and `aws-glue-alpha/test/workflow-triggers.test.ts`.

### Checklist
- [x] My code adheres to the [CONTRIBUTING GUIDE](https://github.com/aws/aws-cdk/blob/main/CONTRIBUTING.md) and [DESIGN GUIDELINES](https://github.com/aws/aws-cdk/blob/main/docs/DESIGN_GUIDELINES.md)

BREAKING CHANGE: Updated casing of `workflow.addconditionalTrigger` to `workflow.addConditionalTrigger`.

----

*By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*

…33515)

### Issue # (if applicable)

Closes #33503.
Closes #30618.

### Reason for this change

When creating a single-zone Aurora cluster and an EC2 instance in development purpose, I want to *pin* the Aurora instance and the EC2 instance in a same availability zone.
We can specify `AvailabilityZone` in Aurora's `AWS::RDS::DBInstance` as same as standalone RDS instances.

### Description of changes

Added `availabilityZone` prop in `ClusterInstanceOptions`

### Describe any new or updated permissions being added

N/A

### Description of how you validated changes

Unit test and integ test.
The integ test also verifies created instances are placed in expected availability zone.

### Checklist
- [x] My code adheres to the [CONTRIBUTING GUIDE](https://github.com/aws/aws-cdk/blob/main/CONTRIBUTING.md) and [DESIGN GUIDELINES](https://github.com/aws/aws-cdk/blob/main/docs/DESIGN_GUIDELINES.md)

----

*By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*

Ran npm-check-updates and yarn upgrade to keep the `yarn.lock` file up-to-date.

…ne role in the trust policy under ff: @aws-cdk/pipelines:reduceStageRoleTrustScope (#33742)

### Issue # (if applicable)
aws-codepipeline creates roles with broad trust policies. 

Closes #33709 

### Reason for this change
Captured in Description of the issue.


### Description of changes
1. Introduced feature flag @aws-cdk/pipelines:reduceStageRoleTrustScope (default: true).
2. Under the feature flag when enabled, the root account principal will not be added to the trust policy of stage role. Instead the stage role can now be assumed by the current role created for the pipeline.


### Describe any new or updated permissions being added
Described above.



### Description of how you validated changes
integ test snapshots are being updated. 


### Checklist
- [ ] My code adheres to the [CONTRIBUTING GUIDE](https://github.com/aws/aws-cdk/blob/main/CONTRIBUTING.md) and [DESIGN GUIDELINES](https://github.com/aws/aws-cdk/blob/main/docs/DESIGN_GUIDELINES.md)

----

*By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*