resource/aws_db_instance: Allow ARN for the replicate_source_db when in the same region

[pccowboy]

I believe this addresses a possible bug we ran into that was triggered by https://github.com/terraform-providers/terraform-provider-aws/pull/865/files and mentioned at https://groups.google.com/forum/#!topic/terraform-tool/zX-bWBZgViI

If you pass both an ARN and a kms_key_id to create a replica in the same region as the master, you get an error of the form "* aws_db_instance.read_replica: Error creating DB Instance: InvalidParameterCombination: Your request does not require the preSignedUrl parameter. Please remove the preSignedUrl parameter and try your request again."

I think this is because of AWS code - in aws/aws-sdk-go/service/rds/customizations.go, a preSignedUrl will get added to the CreateDBInstanceReadReplicaInput if the SourceRegion is set for the replica. If SourceRegion is nil, the presignedURL is skipped.

     58         if originParams.SourceRegion == nil || originParams.PreSignedUrl != nil || originParams.DestinationRegion != nil {
     59                 return
     60         }

I've modified the test for creating a replica, and added two more, one for the replica created with a source ARN in the same region, and one for creating a replica from a source ARN in a different region.

This PR is a replacement for #2386 - due to a bad merge, that branch had a bunch of duplicate commits. This branch has been cleaned up to make a cleaner merge @jen20 @radeksimko

[pccowboy]

@radeksimko Ping? Do you have any information on when this PR might be able to get a review?

[pccowboy]

@bflad Thanks for checking in. Do you have any time to give this a review? I'd really like feedback on whether the tests I added are sufficient.

I'd like to get this into master, as it fixes a blocker for using encrypted read replicas in the same region when using ARNs.

[bflad]

I would prefer someone more familiar with this code/functionality to look at it before I commit myself to looking at it. There is quite a lot in my backlog already.

[pccowboy]

OK, that makes sense. Thanks!

[pccowboy]

@radeksimko ping? Wanted to see about getting a review on this, so I have a chance to rework anything I need to.

[pccowboy]

@radeksimko Hello, this PR just passed its 6-month anniversary - Is there someone I can chat with about getting it reviewed further? @jen20 Gave some feedback on the first iteration of this PR, hoping for more so we can move it along. Thanks

[petergoldstein]

👍

[pccowboy]

@radeksimko Checking in again, do you have any suggestions as to someone who could review this PR?

[petergoldstein]

Doing an incremental rebase to eliminate conflicts and ensure code still runs as expected - should be done by Thursday 6/27.

[zhelding]

Pull request #21306 has significantly refactored the AWS Provider codebase. As a result, most PRs opened prior to the refactor now have merge conflicts that must be resolved before proceeding.

Specifically, PR #21306 relocated the code for all AWS resources and data sources from a single aws directory to a large number of separate directories in internal/service, each corresponding to a particular AWS service. This separation of code has also allowed for us to simplify the names of underlying functions -- while still avoiding namespace collisions.

We recognize that many pull requests have been open for some time without yet being addressed by our maintainers. Therefore, we want to make it clear that resolving these conflicts in no way affects the prioritization of a particular pull request. Once a pull request has been prioritized for review, the necessary changes will be made by a maintainer -- either directly or in collaboration with the pull request author.

For a more complete description of this refactor, including examples of how old filepaths and function names correspond to their new counterparts: please refer to issue #20000.

For a quick guide on how to amend your pull request to resolve the merge conflicts resulting from this refactor and bring it in line with our new code patterns: please refer to our Service Package Refactor Pull Request Guide.