feat(apigatewayv2): fork APIGatewayV2 into its own package

[nija-at]

To preserve backwards compatibility for existing customers, the
generated file apigatewayv2.generated.ts has been copied over as
apigatewayv2.ts. Throughout this file, the API stability has been
noted as deprecated with the note that it has been moved to the new
package.

MOTIVATION

The APIGatewayV2 service APIs are a substantial revision over v1. While
some of the fundamental primitives look and sound similar, such as
Deployment and Stage, the properties they hold and their relationships
have changed subtly.
For instance, in v1, Integration was defined inline to the Method, while
in v2, Integration is modeled as a first class resource. This means that
the same Integration resource can be used across multiple Methods.

The list of properties and their keys that are part of the resource
types with the same name across the two versions vary subtly.
For instance, with the Authorizer resource type across the two versions,
the same property is named AuthorizerCredentialsArn on one and
AuthorizerCredentials in the other.

There is also substantial differences in the two versions of the APIs.
While it's generally true that v1 supports more features than v2, given
that it launched first, there are several cases where the features in
versions have signficantly diverged.
For instance, v1 supports authorizer types - Token, Request and Cognito -
while v2 supports authorizer types - Jwt and Request.

Considering all of these differences between the two versions, trying to
keep both v1 and v2 within the same package would mean that there would
one of two options - either they are modeled behind existing CDK
constructs or as separate ones. With the former option, the complexity
of the construct would increase significantly with having to model the
varying properties, validations and relationships between v1 and v2.
With the latter option, there would be CDK constructs suffixed with
V2 which don't result in a good customer experience.

Finally, there is enough signal here to indicate that the APIGateway
team is motivated to move all of their customers using the new HTTP APIs
in v2. The HTTP APIs (in v2) are cheaper to operate than its
counterpart, the Rest APIs (in v1).

---

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

[aws-cdk-automation]

AWS CodeBuild CI Report

• Result: FAILED
• Build Logs (available for 30 days)

Powered by github-codebuild-logs, available on the AWS Serverless Application Repository

[aws-cdk-automation]

AWS CodeBuild CI Report

• Result: FAILED
• Build Logs (available for 30 days)

Powered by github-codebuild-logs, available on the AWS Serverless Application Repository

[bionicles]

Thanks so much! How do you interpret the build logs? It seems pretty complicated to parse that output into specific actions

[aws-cdk-automation]

AWS CodeBuild CI Report

• Result: FAILED
• Build Logs (available for 30 days)

Powered by github-codebuild-logs, available on the AWS Serverless Application Repository

[aws-cdk-automation]

AWS CodeBuild CI Report

• Result: FAILED
• Build Logs (available for 30 days)

Powered by github-codebuild-logs, available on the AWS Serverless Application Repository

[aws-cdk-automation]

AWS CodeBuild CI Report

• Result: FAILED
• Build Logs (available for 30 days)

Powered by github-codebuild-logs, available on the AWS Serverless Application Repository

[aws-cdk-automation]

AWS CodeBuild CI Report

• Result: SUCCEEDED
• Build Logs (available for 30 days)

Powered by github-codebuild-logs, available on the AWS Serverless Application Repository