Update and extend support for Service Catalog

[ahgittin]

This consists of the following:

• Minor fixes to existing resource_aws_servicecatalog_portfolio support
• Addition of resource_aws_servicecatalog_product building on work done by @trung and @bw-intuit in New Resource: aws_servicecatalog_product (compliment PR 2064) #4980
• Addition of several other resources:
  • To provision products:
    • resource_aws_servicecatalog_portfolio_principal_association
    • resource_aws_servicecatalog_portfolio_product_association
    • resource_aws_servicecatalog_provisioned_product
  • Constraints:
    • resource_aws_servicecatalog_constraint (any constraint)
    • resource_aws_servicecatalog_launch_notification_constraint
    • resource_aws_servicecatalog_launch_role_constraint
    • aws/resource_aws_servicecatalog_launch_template_constraint

The long commit history is in #14281 but has been squashed here to simplify history when merged upstream.
As can be seen there much of the code here is due to @kemitix as well.
`

Community Note

• Please vote on this pull request by adding a 👍 reaction to the original pull request comment to help the community and maintainers prioritize this request
• Please do not leave "+1" or other comments that do not add relevant new information or questions, they generate extra noise for pull request followers and do not help prioritize the request

Relates OR Closes #0000

Closes #4980 #13797 #13834 #13864 #13866 #13837 #14281

Release note for CHANGELOG:

New Resource: `aws_servicecatalog_product`
New Resource: `aws_servicecatalog_portfolio_product_association`
New Resource: `aws_servicecatalog_portfolio_principal_association`
New Resource: `aws_servicecatalog_provisioned_product`
New Resource: `aws_servicecatalog_constraint`
New Resource: `aws_servicecatalog_launch_notification_constraint`
New Resource: `aws_servicecatalog_launch_role_constraint`
New Resource: `aws_servicecatalog_launch_template_constraint`

Output from acceptance testing will be posted when the run completes. (The PRs referenced above do already show the acceptance tests being run on individual features.)

[ahgittin]

@YakDriver I can see the format linter has new rules which this now fails. Probably worth merging master in to this as well.

Any review or input is totally welcome ahead of this but otherwise leave this with us. Happy to mark the PR [WIP] or close it until we've fixed it.

[YakDriver]

Overall, good job! This is looking much more manageable.

To finish this off, this is my proposal. For a first phase, I've done a very quick review and noted some general items that need to be fixed below. Are you able and willing to fix these in the relatively near future?

After the first phase, in the second phase, I'll fix the final items after going through with a fine-tooth comb. Make sure you've checked "Allow edits from maintainers." You will receive all credit for your work - I will only add commits.

This approach should help us get this done relatively quickly.

Phase 1, general areas for you to fix:

• Please fix the conflict
• Remove TF pre-0.11 HCL syntax: "${data.thing.example}" -> data.thing.example
• Fix the acceptance test HCL formatting issues found by the linter: use spaces not tabs, align the = signs
• Fix the other linter issues. Let me know if you have questions.
• Include ErrorCheck in all the acceptance tests (see https://github.com/hashicorp/terraform-provider-aws/blob/main/docs/contributing/running-and-writing-acceptance-tests.md#errorchecks)
• Make sure to not change file modes (for example, provider.go is being changed from 100644 -> 100755)
• Inside each resource file, the Schema arguments and attributes (and sub-args/attributes) should be alphabetized
• If they exist, always use types defined in the AWS packages rather than define new types
• Check out the examples of expanders and flatteners: https://github.com/hashicorp/terraform-provider-aws/blob/main/docs/contributing/data-handling-and-conversion.md#expand-functions-for-blocks, https://github.com/hashicorp/terraform-provider-aws/blob/main/docs/contributing/data-handling-and-conversion.md#flatten-functions-for-blocks
• Ideally, use the generic naming (apiObject, apiObjects, tfMapRaw, tfMap, tfList) instead of API-specific names (assertions)
• In the docs, instead of "The following arguments are supported:" split the list into two, required and optional, with these phrases “The following arguments are required:” and “The following arguments are optional:”.
• In the docs (and anywhere in the code that it makes sense - such as a group of d.Set() statements), make sure that all argument and attribute lists are alphabetical. This helps avoid contributors adding the same arguments twice since they didn't see them in the list. (This provides an example of some of the current best practices for documentation: https://registry.terraform.io/providers/hashicorp/aws/latest/docs/resources/mq_broker)
• In the docs, avoid using articles to describe arguments and attributes. In other words, in this example, "authentication_strategy - (Optional) The authentication strategy..." the word "The" can be dropped. It should be "authentication_strategy - (Optional) Authentication strategy...".

[ahgittin]

Thanks @YakDriver . We based this original work on pre-existing files but I guess we picked not great exemplars, and the linter passed at the original PR, but these are all good new requirements and make sense.

We'll let you know when we can address them -- hopefully soon.

[YakDriver]

@ahgittin Can you have your work up to where you're at currently pushed by Friday (April 9)? I understand completely that you are likely to have other priorities. Based on our commitments, I will take over where ever you leave off to get this off the ground. Thank you for all your help! I may cherry pick your commits to another branch but you will still be credited for them.

[TheRealKim]

Is there anything I can do to help move this PR forward? I am not really an expert in GO but can probably figure out how to fix linting and/or documentation issues if any. I have build the code in this commit locally and the terraform resource resource_aws_servicecatalog_provisioned_product is exactly what I am looking for to be able to continue my project. So would it be a possibility to cherry pick the code for this resource as well and have it in a separate PR?
Thanks a lot ahgittin and Yakdriver for already adding more support for AWS service catalog for terraform!

[YakDriver]

Since these resource have been added, I'm going to close this PR.

[github-actions]

I'm going to lock this pull request because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues.
If you have found a problem that seems related to this change, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.