Merge logic for extending resources with the existing framework
using `resources.Resources` has some surprising behaviours.
This introduces a more formalized definition for extending resources, where
`Metadata` and `Properties` will be shallowly merged (the values for existing
keys will be replaced instead of merged), the `DependsOn` list will be added
to, and the values for `CreationPolicy`, `DeletionPolicy`, `UpdatePolicy`, and
`UpdateReplacePolicy` will be replaced if they exist in the extension.
Extension of other resource attributes is not supported at this time.
There are use cases where an API creator does not have permissions to
add permissions to the custom authorizer lambda; one example is when
the custom authorizer lambda exists in a separate AWS account. In these
cases, we need to be able to omit the `AWS::Lambda::Permission` resource
from the stack.
This change adds the `managedExternally` attribute to the `authorizer`.
When `managedExternally` is `true`, the stack will not create the
`AWS::Lambda::Permission` resource.
**Important note:** The permission does still need to be created before
the stack is deployed, or creating the authorizer will fail.
Dashboard plugin at intialization eventually resolves credentials
for a framework, and as region resolution comes with it,
it also resolves region.
Still it happens prior variables resolution and there's
no guarantee that region value is resolved.
Fixes https://github.com/serverless/enterprise-plugin/issues/340
Until now, failed stack deploys when using deploymentBucket to specify
an existing bucket were left in ROLLBACK_COMPLETE state.
This required manual 'sls remove' before a redeploy.
Fixes#6612, follow-up of incomplete fix in #5631
Issue was fixed on AWS side, and by next week it should be fixed for
gov-cloud regions.
Still in a meantime other AWS issue emerged,
An "A conflicting deployment is in progress." error,
Which happens only when workaround in question is involved
Fixes#7137
