Fix sql_database_instance to include backup_configuration in create request

[roaks3]

Fixes b/257534640 (TF plan allows google_sql_database_instance.replica to define a backup configuration)

SQL database instances do not allow replicas to enable backups. For example, the following config will fail:

resource "google_sql_database_instance" "main" {
  name             = "main-instance"
  ...
}

resource "google_sql_database_instance" "replica" {
  name             = "replica-instance"

  # Defines instance as a replica
  master_instance_name = "${google_sql_database_instance.main.name}"    
  replica_configuration {
    failover_target = false
  }

  settings {
    ...
    # Enables backups
    backup_configuration {
      enabled = true
      point_in_time_recovery_enabled = true
    }
  }
}

Problem
Previously, config like this would correctly result in an error, but the replica would still be created with the backup_configuration omitted. This caused issues with consecutive terraform apply calls where the first succeeded, but the second failed with no changes to the config.

Root cause
We were using some custom behavior for backup_configuration.binary_log_enabled that removed it from the initial create request, and then added it back to the instance with a subsequent patch request. This behavior had a bug that caused the entire backup_configuration to be removed and not get patched if binary_log_enabled was false for a replica.

Resolution
This PR proposes fixing the issue by leaving the backup_configuration on the create request, so that the server can validate the full configuration before creating any entities. The one exception is binary_log_enabled, which cannot be set to true until after a replica is created. In that case, we make the initial create request with binary_log_enabled = false, and then use the subsequent patch call to set it to true like before.

If this PR is for Terraform, I acknowledge that I have:

• Searched through the issue tracker for an open issue that this either resolves or contributes to, commented on it to claim it, and written "fixes {url}" or "part of {url}" in this PR description. If there were no relevant open issues, I opened one and commented that I would like to work on it (not necessary for very small changes).
• Generated Terraform, and ran make test and make lint to ensure it passes unit and linter tests.
• Ensured that all new fields I added that can be set by a user appear in at least one example (for generated resources) or third_party test (for handwritten resources or update tests).
• Ran relevant acceptance tests (If the acceptance tests do not yet pass or you are unable to run them, please let your reviewer know).
• Read the Release Notes Guide before writing my release note below.

Release Note Template for Downstream PRs (will be copied)

sql: fix `googe_sql_database_instance` to include `backup_configuration` in initial create request

[modular-magician]

Hello! I am a robot who works on Magic Modules PRs.

I've detected that you're a community contributor. @c2thorn, a repository maintainer, has been assigned to assist you and help review your changes.

❓ First time contributing? Click here for more details

---

Your assigned reviewer will help review your code by:

• Ensuring it's backwards compatible, covers common error cases, etc.
• Summarizing the change into a user-facing changelog note.
• Passes tests, either our "VCR" suite, a set of presubmit tests, or with manual test runs.

You can help make sure that review is quick by running local tests and ensuring they're passing in between each push you make to your PR's branch. Also, try to leave a comment with each push you make, as pushes generally don't generate emails.

If your reviewer doesn't get back to you within a week after your most recent change, please feel free to leave a comment on the issue asking them to take a look! In the absence of a dedicated review dashboard most maintainers manage their pending reviews through email, and those will sometimes get lost in their inbox.

---

[roaks3]

Confirms that backup_configuration.enabled = true fails for a replica

[roaks3]

Confirms that backup_configuration.enabled = false is allowed for a replica

[modular-magician]

Hi there, I'm the Modular magician. I've detected the following information about your changes:

Diff report

Your PR generated some diffs in downstreams - here they are.

Terraform GA: Diff ( 2 files changed, 18 insertions(+), 9 deletions(-))
Terraform Beta: Diff ( 2 files changed, 18 insertions(+), 9 deletions(-))
TF Validator: Diff ( 2 files changed, 3 insertions(+), 3 deletions(-))

[modular-magician]

Tests analytics

Total tests: 2260
Passed tests 2016
Skipped tests: 241
Failed tests: 3

Action taken

Triggering VCR tests in RECORDING mode for the tests that failed during VCR. Click here to see the failed tests

TestAccSqlDatabaseInstance_replica|TestAccComputeForwardingRule_update|TestAccFirebaserulesRelease_BasicRelease

[modular-magician]

Tests passed during RECORDING mode:
TestAccSqlDatabaseInstance_replica[Debug log]
TestAccComputeForwardingRule_update[Debug log]
TestAccFirebaserulesRelease_BasicRelease[Debug log]

All tests passed
View the build log or the debug log for each test

[c2thorn]

Definitely an oversight on the previous implementation. Thanks for the fix!