chore: update outdated repo links and package paths (#26619)

Update some outdated repository links and package paths since [repo remodeling](#24376).

----

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

Author: clueleaf

CONTRIBUTING.md

@@ -352,8 +352,8 @@ assertions against the deployed infrastructure.
 ```
 
 Examples:
-* [integ.destinations.ts](https://github.com/aws/aws-cdk/blob/master/packages/%40aws-cdk/aws-lambda-destinations/test/integ.destinations.ts#L7)
-* [integ.put-events.ts](https://github.com/aws/aws-cdk/blob/main/packages/%40aws-cdk/aws-stepfunctions-tasks/test/eventbridge/integ.put-events.ts)
+* [integ.destinations.ts](https://github.com/aws/aws-cdk/blob/main/packages/%40aws-cdk-testing/framework-integ/test/aws-lambda-destinations/test/integ.destinations.ts#L7)
+* [integ.put-events.ts](https://github.com/aws/aws-cdk/blob/main/packages/%40aws-cdk-testing/framework-integ/test/aws-stepfunctions-tasks/test/eventbridge/integ.put-events.ts)
 
 **What if you cannot run integration tests**
 

INTEGRATION_TESTS.md

@@ -49,8 +49,8 @@ an integration test for the new feature can ensure that it works and avoid unnec
 
 **3. Involves configuring resource types across services (i.e. integrations)**
 For example, you are adding functionality that allows for service x to integrate with service y.
-A good example of this is the [aws-stepfunctions-tasks](./packages/@aws-cdk/aws-stepfunctions-tasks) or
-[aws-apigatewayv2-integrations](./packages/@aws-cdk/aws-apigatewayv2-integrations) modules. Both of these
+A good example of this is the [aws-stepfunctions-tasks](./packages/aws-cdk-lib/aws-stepfunctions-tasks) or
+[aws-apigatewayv2-integrations-alpha](./packages/@aws-cdk/aws-apigatewayv2-integrations-alpha) modules. Both of these
 have L2 constructs that provide functionality to integrate services.
 
 Sometimes these integrations involve configuring/formatting json/vtl or some other type of data.
@@ -82,8 +82,8 @@ Lambda Function would look like this:
 
 _integ.lambda.ts_
 ```ts
-import * as iam from '@aws-cdk/aws-iam';
-import * as cdk from '@aws-cdk/core';
+import * as iam from 'aws-cdk-lib/aws-iam';
+import * as cdk from 'aws-cdk-lib/core';
 import * as lambda from '../lib';
 import * as integ from '@aws-cdk/integ-tests-alpha';
 
@@ -230,11 +230,11 @@ to deploy the Lambda Function _and_ then rerun the assertions to ensure that the
 ### Assertions
 
 Sometimes it is necessary to perform some form of _assertion_ against the deployed infrastructure to validate that the
-test succeeds. A good example of this is the `@aws-cdk/aws-stepfunctions-tasks` module which creates integrations between
+test succeeds. A good example of this is the `aws-cdk-lib/aws-stepfunctions-tasks` module which creates integrations between
 AWS StepFunctions and other AWS services. 
 
-If we look at the [integ.put-events.ts](https://github.com/aws/aws-cdk/blob/main/packages/%40aws-cdk/aws-stepfunctions-tasks/test/eventbridge/integ.put-events.ts)
-integration test we can see that we are creating an `@aws-cdk/aws-events.EventBus` along with a `@aws-cdk/aws-stepfunctions.StateMachine`
+If we look at the [integ.put-events.ts](https://github.com/aws/aws-cdk/blob/main/packages/%40aws-cdk-testing/framework-integ/test/aws-stepfunctions-tasks/test/eventbridge/integ.put-events.ts)
+integration test we can see that we are creating an `aws-cdk-lib/aws-events.EventBus` along with a `aws-cdk-lib/aws-stepfunctions.StateMachine`
 which will send an event to the `EventBus`. In a typical integration test we would just deploy the test and the fact that the
 infrastructure deployed successfully would be enough of a validation that the test succeeded. In this case though, we ideally
 want to validate that the _integration_ connecting `StepFunctions` to the `EventBus` has been setup correctly, and the only
@@ -269,8 +269,8 @@ Not every test requires an assertion. We typically do not need to assert CloudFo
 with Encryption, we do not need to assert that Encryption is set on the bucket. We can trust that the CloudFormation behavior works.
 Some things you should look for in deciding if the test needs an assertion:
 
-- Integrations between services (i.e. integration libraries like `@aws-cdk/aws-lambda-destinations`, `@aws-cdk/aws-stepfunctions-tasks`, etc)
-- Anything that bundles or deploys custom code (i.e. does a Lambda function bundled with `@aws-cdk/aws-lambda-nodejs` still invoke or did we break bundling behavior)
+- Integrations between services (i.e. integration libraries like `aws-cdk-lib/aws-lambda-destinations`, `aws-cdk-lib/aws-stepfunctions-tasks`, etc)
+- Anything that bundles or deploys custom code (i.e. does a Lambda function bundled with `aws-cdk-lib/aws-lambda-nodejs` still invoke or did we break bundling behavior)
 - IAM/Networking connections.
   - This one is a bit of a judgement call. Most things do not need assertions, but sometimes we handle complicated configurations involving IAM permissions or
     Networking access.

design/aws-ecs/aws-ecs-fargate-capacity-providers.md

@@ -103,11 +103,11 @@ This new field would be added to the BaseService, not only for better extensibil
 
 Implications Setting Launch Type
 
-Since it can be reasonably assumed that any CapacityProvideStrategies defined on the Service are what the customer intends to use on the Service, the LaunchType will *not* be set on the Service if CapacityProvideStrategies are specified. This is similar to how the LaunchType field is unset if the service uses an external DeploymentController (https://github.com/aws/aws-cdk/blob/main/packages/%40aws-cdk/aws-ecs/lib/base/base-service.ts#L374).
+Since it can be reasonably assumed that any CapacityProvideStrategies defined on the Service are what the customer intends to use on the Service, the LaunchType will *not* be set on the Service if CapacityProvideStrategies are specified. This is similar to how the LaunchType field is unset if the service uses an external DeploymentController (https://github.com/aws/aws-cdk/blob/main/packages/aws-cdk-lib/aws-ecs/lib/base/base-service.ts#L587).
 
 On the other hand, this intent would not be as obvious with Default Capacity Provider Strategies defined a cluster. A *defaultCapacityProviderStrategy* specified on a cluster is used for any service that does not specify either a launchType or its own CapacityProviderStrategies. From the point of view of the ECS APIs, similar to how custom CapacityProvideStrategies defined on the Service are expected to supersede the defaultCapacityProviderStrategy on a cluster, the expected behavior for an ECS Service that specifies a launchType is for it to also ignore the Cluster’s defaultCapacityProviderStrategy.
 
-However, since the two Service constructs in the CDK (Ec2Service and FargateService) do not support having the launchType field passed in explicitly, it would not possible to infer whether the intent of the customer using one of these Service constructs is to use the implied launchType (currently set under the hood in the service’s constructor (https://github.com/aws/aws-cdk/blob/main/packages/%40aws-cdk/aws-ecs/lib/fargate/fargate-service.ts#L155)) or the defaultCapacityProviderStrategy.  For this reason, we will not be adding the  defaultCapacityProviderStrategy field on the Cluster construct for this iteration.
+However, since the two Service constructs in the CDK (Ec2Service and FargateService) do not support having the launchType field passed in explicitly, it would not possible to infer whether the intent of the customer using one of these Service constructs is to use the implied launchType (currently set under the hood in the service’s constructor (https://github.com/aws/aws-cdk/blob/main/packages/aws-cdk-lib/aws-ecs/lib/fargate/fargate-service.ts#L134) or the defaultCapacityProviderStrategy.  For this reason, we will not be adding the  defaultCapacityProviderStrategy field on the Cluster construct for this iteration.
 
 _*Note*_: Future for support will be dependent on a re-design of the existing Service strategies. This will be treated in v2 of the ECS modules, likely with a single Service L2 construct and deprecation of the Ec2Service and FargateService constructs.
 

design/aws-ecs/aws-ecs-priv-registry-support.md

@@ -2,11 +2,11 @@
 
 To address issue [#1698](https://github.com/aws/aws-cdk/issues/1698), the ECS construct library should provide a way for customers to specify [`repositoryCredentials`](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_ContainerDefinition.html#ECS-Type-ContainerDefinition-repositoryCredentials) on their container.
 
-Minimally, this would mean adding a new string field on `ContainerDefinition`, however this doesn't provide any added value in terms of logical grouping or resource creation. We can instead modify the existing ECS CDK construct [`ContainerImage`](https://github.com/aws/aws-cdk/blob/main/packages/%40aws-cdk/aws-ecs/lib/container-image.ts) so that repository credentials are specified along with the image they're meant to access.
+Minimally, this would mean adding a new string field on `ContainerDefinition`, however this doesn't provide any added value in terms of logical grouping or resource creation. We can instead modify the existing ECS CDK construct [`ContainerImage`](https://github.com/aws/aws-cdk/blob/main/packages/aws-cdk-lib/aws-ecs/lib/container-image.ts) so that repository credentials are specified along with the image they're meant to access.
 
 ## General approach
 
-The [`ecs.ContainerImage`](https://github.com/aws/aws-cdk/blob/main/packages/%40aws-cdk/aws-ecs/lib/container-image.ts) class already includes constructs for 3 types of images:
+The [`ecs.ContainerImage`](https://github.com/aws/aws-cdk/blob/main/packages/aws-cdk-lib/aws-ecs/lib/container-image.ts) class already includes constructs for 3 types of images:
 
 * DockerHubImage
 * EcrImage

docs/DESIGN_GUIDELINES.md

@@ -193,7 +193,7 @@ exist in the CDK will be removed in the next CDK major version (CDKv2).
 
 AWS resources are organized into modules based on their AWS service. For
 example, the "Bucket" resource, which is offered by the Amazon S3 service will
-be available under the **@aws-cdk/aws-s3** module. We will use the “aws-” prefix
+be available under the **aws-cdk-lib/aws-s3** module. We will use the “aws-” prefix
 for all AWS services, regardless of whether their marketing name uses an
 “Amazon” prefix (e.g. “Amazon S3”). Non-AWS services supported by AWS
 CloudFormation (like the Alexa::ASK namespace) will be **@aws-cdk/alexa-ask**.
@@ -203,13 +203,13 @@ consistent with the AWS SDKs and AWS CloudFormation _[awslint:module-name]_.
 
 All major versions of an AWS namespace will be mastered in the AWS Construct
 Library under the root namespace. For example resources of the **ApiGatewayV2**
-namespace will be available under the **@aws-cdk/aws-apigateway** module (and
+namespace will be available under the **aws-cdk-lib/aws-apigateway** module (and
 not under “v2) _[awslint:module-v2]_.
 
 In some cases, it makes sense to introduce secondary modules for a certain
 service (e.g. aws-s3-notifications, aws-lambda-event-sources, etc). The name of
 the secondary module will be
-**@aws-cdk/aws-xxx-\<secondary-module\>**_[awslint:module-secondary]_.
+**aws-cdk-lib/aws-xxx-\<secondary-module\>**_[awslint:module-secondary]_.
 
 Documentation for how to use secondary modules should be in the main module. The
 README file should refer users to the central module

packages/@aws-cdk-testing/framework-integ/test/aws-cloudwatch/test/integ.alarm-and-dashboard.ts

@@ -1,6 +1,6 @@
 // Integration test to deploy some resources, create an alarm on it and create a dashboard.
 //
-// Because literally every other library is going to depend on @aws-cdk/aws-cloudwatch, we drop down
+// Because literally every other library is going to depend on aws-cdk-lib/aws-cloudwatch, we drop down
 // to the very lowest level to create CloudFormation resources by hand, without even generated
 // library support.
 

packages/@aws-cdk-testing/framework-integ/test/aws-cloudwatch/test/integ.math-alarm-and-dashboard.ts

@@ -1,6 +1,6 @@
 // Integration test to deploy some resources, create an alarm on it and create a dashboard.
 //
-// Because literally every other library is going to depend on @aws-cdk/aws-cloudwatch, we drop down
+// Because literally every other library is going to depend on aws-cdk-lib/aws-cloudwatch, we drop down
 // to the very lowest level to create CloudFormation resources by hand, without even generated
 // library support.
 

packages/@aws-cdk-testing/framework-integ/test/aws-codecommit/test/integ.codecommit-events.ts

@@ -10,7 +10,7 @@ const repo = new codecommit.Repository(stack, 'Repo', {
 });
 const topic = new sns.Topic(stack, 'MyTopic');
 
-// we can't use @aws-cdk/aws-events-targets.SnsTopic here because it will
+// we can't use aws-cdk-lib/aws-events-targets.SnsTopic here because it will
 // create a cyclic dependency with codebuild, so we just fake it
 repo.onReferenceCreated('OnReferenceCreated', {
   target: {

packages/@aws-cdk-testing/framework-integ/test/aws-eks/test/integ.eks-cluster-ipv6.ts

@@ -350,7 +350,7 @@ class EksClusterStack extends Stack {
 }
 
 // this test uses both the bottlerocket image and the inf1 instance, which are only supported in these
-// regions. see https://github.com/aws/aws-cdk/tree/main/packages/%40aws-cdk/aws-eks#bottlerocket
+// regions. see https://github.com/aws/aws-cdk/tree/main/packages/aws-cdk-lib/aws-eks#bottlerocket
 // and https://aws.amazon.com/about-aws/whats-new/2019/12/introducing-amazon-ec2-inf1-instances-high-performance-and-the-lowest-cost-machine-learning-inference-in-the-cloud/
 const supportedRegions = [
   'us-east-1',

packages/@aws-cdk-testing/framework-integ/test/aws-eks/test/integ.eks-cluster.ts

@@ -323,7 +323,7 @@ class EksClusterStack extends Stack {
 }
 
 // this test uses both the bottlerocket image and the inf1 instance, which are only supported in these
-// regions. see https://github.com/aws/aws-cdk/tree/main/packages/%40aws-cdk/aws-eks#bottlerocket
+// regions. see https://github.com/aws/aws-cdk/tree/main/packages/aws-cdk-lib/aws-eks#bottlerocket
 // and https://aws.amazon.com/about-aws/whats-new/2019/12/introducing-amazon-ec2-inf1-instances-high-performance-and-the-lowest-cost-machine-learning-inference-in-the-cloud/
 const supportedRegions = [
   'us-east-1',