fix: honour the AllowCredentials CORS option in SAM templates

[discorev]

Which issue(s) does this change fix?

#1645

Why is this change necessary?

This change is needed to complete an incomplete feature in the local API CORS implementation. Currently the AllowCredentials CORS option is ignored in the local API mock and blocks any local development that has a CORS requirement and needs the Access-Control-Allow-Credentials header to be set.

How does it address the issue?

Whilst parsing CORS options for a REST API, the AllowCredentials option is parsed allowing for a boolean or quoted string value. If and only if this value is a representation of true, the header is set to the string true

Whilst parsing CORS options for a Http API the AllowCredentials options is parsed only allowing for a boolean value (following the documentation). If this is set to true, the header is set to the string true

The header is always output as a lower-cased string to be compliant with section 5.6 of RFC7480

There are no new dependancies introduced and this does not impact any other areas of functionality.

What side effects does this change have?

There are no side effects outside of having the Access-Control-Allow-Credentials header set when the template demands it.

Checklist

• Add input/output type hints to new functions/methods
• Write design document (Do I need to write a design document?)
• Write unit tests
• Write/update functional tests
• Write/update integration tests
• make pr passes
• make update-reproducible-reqs if dependencies were changed
• Write documentation

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

[hoffa]

Thanks for the PR!

Related PRs for reference: #1648 (reverted in #1664) and #2058.

[hoffa]

Some minor comments; overall looks great!

[hoffa]

Thanks @discorev; merged!