chore(docs): Fix broken md links (#18384)

Hi, 

I noticed some broken links in the docs and decided to scan for and fix some of them.

There was one that I wasn't able to fix easily in './design/construct-tree.md' which links to some prototype at 
https://github.com/aws/aws-cdk/tree/prototypes/cdk-look

I guess that prototype just doesn't exist anymore.

----

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

CONTRIBUTING.md

@@ -662,7 +662,7 @@ extension](https://marketplace.visualstudio.com/items?itemName=dbaeumer.vscode-e
 
 #### pkglint
 
-The `pkglint` tool "lints" package.json files across the repo according to [rules.ts](tools/pkglint/lib/rules.ts).
+The `pkglint` tool "lints" package.json files across the repo according to [rules.ts](tools/@aws-cdk/pkglint/lib/rules.ts).
 
 To evaluate (and attempt to fix) all package linting issues in the repo, run the following command from the root of the
 repository (after bootstrapping):

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

@@ -2,7 +2,7 @@
 
 ## Objective
 
-Since Capacity Providers are now supported in CloudFormation, incorporating support for Fargate Spot capacity has been one of the [top asks](https://github.com/aws/aws-cdk/issues?q=is%3Aissue+is%3Aopen+label%3A%40aws-cdk%2Faws-ecs+sort%3Areactions-%2B1-desc) for the ECS CDK module, with over 60 customer reactions. While there are still some outstanding issues regarding capacity provider support in general, specifically regarding cyclic workflows with named clusters (See: [CFN issue](http://%20https//github.com/aws/containers-roadmap/issues/631#issuecomment-702580141)), we should be able to move ahead with supporting `FARGATE` and `FARGATE_SPOT` capacity providers with our existing FargateService construct.
+Since Capacity Providers are now supported in CloudFormation, incorporating support for Fargate Spot capacity has been one of the [top asks](https://github.com/aws/aws-cdk/issues?q=is%3Aissue+is%3Aopen+label%3A%40aws-cdk%2Faws-ecs+sort%3Areactions-%2B1-desc) for the ECS CDK module, with over 60 customer reactions. While there are still some outstanding issues regarding capacity provider support in general, specifically regarding cyclic workflows with named clusters (See: [CFN issue](https://github.com/aws/containers-roadmap/issues/631#issuecomment-702580141)), we should be able to move ahead with supporting `FARGATE` and `FARGATE_SPOT` capacity providers with our existing FargateService construct.
 
 See: https://github.com/aws/aws-cdk/issues/5850
 
@@ -118,4 +118,3 @@ One alternative considered was to provide a more magical experience by populatin
 For future extensibility, we can however add an `addCapacityProvider` method on the Cluster resource, to allow modifying the cluster CapacityProviders field post-construction.
 
 Another option would be to create a new FargateCluster resource, that would have the two Fargate capacity providers set by default. The main advantage with this alternative would be that it would be consistent with the current Console experience, which sets the Fargate capacity providers for you if you choose the “Networking Only” cluster template via the cluster wizard. The downside is that it would be a more restrictive resource model that would go back on the decision to have a single generic ECS Cluster resource that could potentially contain both Fargate and EC2 services or tasks. Given that we are moving towards more generic versions of ECS resources, this is not a preferable solution. That being said, in the current iteration we can set the Fargate Capacity Providers on the cluster by default, but put them behind a feature flag, which we would be able to remove in the v2 version of the ECS module. Using the feature flag would ensure that there would not be a diff in the generated CFN template for existing customers defining ECS clusters in their stack who redeploy using an updated version of the CDK.
-

packages/@aws-cdk/aws-eks-legacy/README.md

@@ -49,7 +49,7 @@ cluster.addResource('mypod', {
 });
 ```
 
-Here is a [complete sample](https://github.com/aws/aws-cdk/blob/master/packages/%40aws-cdk/aws-eks/test/integ.eks-kubectl.lit.ts).
+Here is a [complete sample](https://github.com/aws/aws-cdk/blob/master/packages/@aws-cdk/aws-eks-legacy/test/integ.eks-kubectl.lit.ts).
 
 ### Capacity
 

packages/@aws-cdk/aws-eks/README.md

@@ -1174,11 +1174,11 @@ chart2.node.addDependency(chart1);
 
 [CDK8s](https://cdk8s.io/) is an open-source library that enables Kubernetes manifest authoring using familiar programming languages. It is founded on the same technologies as the AWS CDK, such as [`constructs`](https://github.com/aws/constructs) and [`jsii`](https://github.com/aws/jsii).
 
-> To learn more about cdk8s, visit the [Getting Started](https://github.com/awslabs/cdk8s/tree/master/docs/getting-started) tutorials.
+> To learn more about cdk8s, visit the [Getting Started](https://cdk8s.io/docs/latest/getting-started/) tutorials.
 
 The EKS module natively integrates with cdk8s and allows you to apply cdk8s charts on AWS EKS clusters via the `cluster.addCdk8sChart` method.
 
-In addition to `cdk8s`, you can also use [`cdk8s+`](https://github.com/awslabs/cdk8s/tree/master/packages/cdk8s-plus), which provides higher level abstraction for the core kubernetes api objects.
+In addition to `cdk8s`, you can also use [`cdk8s+`](https://cdk8s.io/docs/latest/plus/), which provides higher level abstraction for the core kubernetes api objects.
 You can think of it like the `L2` constructs for Kubernetes. Any other `cdk8s` based libraries are also supported, for example [`cdk8s-debore`](https://github.com/toricls/cdk8s-debore).
 
 To get started, add the following dependencies to your `package.json` file:
@@ -1290,7 +1290,7 @@ export class LoadBalancedWebService extends constructs.Construct {
 
 If you find yourself unable to use `cdk8s+`, or just like to directly use the `k8s` native objects or CRD's, you can do so by manually importing them using the `cdk8s-cli`.
 
-See [Importing kubernetes objects](https://github.com/awslabs/cdk8s/tree/master/packages/cdk8s-cli#import) for detailed instructions.
+See [Importing kubernetes objects](https://cdk8s.io/docs/latest/cli/import/) for detailed instructions.
 
 ## Patching Kubernetes Resources
 

packages/@aws-cdk/aws-iam/README.md

@@ -202,7 +202,7 @@ const principal = new iam.AccountPrincipal('123456789000')
 
 > NOTE: If you need to define an IAM condition that uses a token (such as a
 > deploy-time attribute of another resource) in a JSON map key, use `CfnJson` to
-> render this condition. See [this test](./test/integ-condition-with-ref.ts) for
+> render this condition. See [this test](./test/integ.condition-with-ref.ts) for
 > an example.
 
 The `WebIdentityPrincipal` class can be used as a principal for web identities like

packages/@aws-cdk/aws-route53-targets/README.md

@@ -108,7 +108,7 @@ See [the documentation on DNS addressing](https://docs.aws.amazon.com/global-acc
 
 * InterfaceVpcEndpoints
 
-**Important:** Based on the CFN docs for VPCEndpoints - [see here](attrDnsEntries) - the attributes returned for DnsEntries in CloudFormation is a combination of the hosted zone ID and the DNS name. The entries are ordered as follows: regional public DNS, zonal public DNS, private DNS, and wildcard DNS. This order is not enforced for AWS Marketplace services, and therefore this CDK construct is ONLY guaranteed to work with non-marketplace services.
+**Important:** Based on the CFN docs for VPCEndpoints - [see here](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-ec2-vpcendpoint.html#aws-resource-ec2-vpcendpoint-return-values) - the attributes returned for DnsEntries in CloudFormation is a combination of the hosted zone ID and the DNS name. The entries are ordered as follows: regional public DNS, zonal public DNS, private DNS, and wildcard DNS. This order is not enforced for AWS Marketplace services, and therefore this CDK construct is ONLY guaranteed to work with non-marketplace services.
 
   ```ts
   import * as ec2 from '@aws-cdk/aws-ec2';

packages/@aws-cdk/cloud-assembly-schema/CONTRIBUTING.md

@@ -59,7 +59,7 @@ This means that breaking changes will be rejected. These include:
 - Changing the type of the property.
 
 In addition, the interfaces defined here are programatically exposed to users, via the `manifest` 
-property of the [`CloudAssembly`]((../cx-api/lib/cloud-assembly.ts)) class. This means that the following are 
+property of the [`CloudAssembly`](../cx-api/lib/cloud-assembly.ts) class. This means that the following are 
 also considered breaking changes:
 
 - Changing a property from *required* to *optional*.

packages/aws-cdk/CONTRIBUTING.md

@@ -131,7 +131,7 @@ Its value can either be that of `CANDIDATE_VERSION` (for testing against the lat
 
 Following are the steps involved in running these tests:
 
-1. Run [`./bump-candidate.sh`](../../bump-candidate.sh) to differentiate between the local version and the published version. For example, if the version in `lerna.json` is `1.67.0`, this script will result in a version `1.67.0-rc.0`. This is needed so that we can launch a verdaccio instance serving local tarballs without worrying about conflicts with the public npm uplink. This will help us avoid version quirks that might happen during the *post-release-pre-merge-back* time window.
+1. Run [`./bump-candidate.sh`](../../scripts/bump-candidate.sh) to differentiate between the local version and the published version. For example, if the version in `lerna.json` is `1.67.0`, this script will result in a version `1.67.0-rc.0`. This is needed so that we can launch a verdaccio instance serving local tarballs without worrying about conflicts with the public npm uplink. This will help us avoid version quirks that might happen during the *post-release-pre-merge-back* time window.
 
 2. Run [`./align-version.sh`](../../scripts/align-version.sh) to configure the above version in all our packages.
 

packages/awslint/README.md

@@ -17,7 +17,7 @@
 
 A linter for the AWS Construct Library's API. It reflects a construct library's
 module via it's `.jsii` manifest and checks that the module adheres to the [AWS
-Resource Construct Design Guidelines](../../DESIGN_GUIDELINES.md).
+Resource Construct Design Guidelines](../../docs/DESIGN_GUIDELINES.md).
 
 ## Usage
 
@@ -139,6 +139,6 @@ resource-class: every resource must have a resource class (L2)
 ...
 ```
 
-The [AWS Resource Construct Design Guidelines](../../DESIGN_GUIDELINES.md) document
-includes references for all rules. For example, see [#construct-interface](../../DESIGN_GUIDELINES.md#construct-interface)
+The [AWS Resource Construct Design Guidelines](../../docs/DESIGN_GUIDELINES.md) document
+includes references for all rules. For example, see [#construct-interface](../../docs/DESIGN_GUIDELINES.md#construct-interface)
 for a discussion about the "construct-interface" rule.

tools/@aws-cdk/cdk-release/README.md

@@ -15,7 +15,7 @@ like messing up the headings,
 and having problems with both V1 and V2 tags in the same repo).
 
 This library is called from the
-[`bump.js` file](../../scripts/bump.js),
-which is called from the [`bump.sh` script](../../bump.sh),
+[`bump.js` file](../../../scripts/bump.js),
+which is called from the [`bump.sh` script](../../../bump.sh),
 which is called by a CodeBuild job that creates the 'bump'
 PR every time we perform a CDK release.

tools/@aws-cdk/individual-pkg-gen/README.md

@@ -3,7 +3,7 @@
 The tool contains the logic of the copying the packages we release individually,
 instead of vending them inside `aws-cdk-lib`,
 from their original V1 form in `packages/@aws-cdk/` to `packages/individual-packages`.
-It's called from the [`transform.sh` script](../../scripts/transform.sh).
+It's called from the [`transform.sh` script](../../../scripts/transform.sh).
 
 We do the translation in 2 phases: