Add backup_config resource

[fantapop]

Note that this commit is still a work in progress as the final SDK changes required for its use are not deployed yet but I've tested it locally and it's in a good place for feedback.

@mdlinville I was particularly hoping to get your feedback on the documentation that I added. This ended up being a documentation heavy resource.

Commit checklist

• Changelog
• Doc gen (make generate)
• Integration test(s)
• Acceptance test(s)
• Example(s)

I'm not super clear on how well the large block of documentation will render on the terraform docs site. Here is the how the value looks with my local rendering. Note: I've updated this screenshot after the latest batch of edits.

[kathancox]

Added some comments for the doc component of this. I wasn't sure of the constraints here, so feel free to take the comments as you need. I can take another look when you need it.

[fantapop]

@kathancox I made a round of changes. You can see the diff here: https://github.com/cockroachdb/terraform-provider-cockroach/compare/48c107eae8a9bdc446d998fda84c1b9d1daa4d93..5a50b9916d3b01d54a25b5ee51a051f2d4bc34c9

I think I've incorporated everything but I may have missed something. Please feel free to make more comments if you have further edits.

[kathancox]

The back_config.md doc lgtm

[fantapop]

I was just able to do some local testing of this and it's performing as expected. One oddity which I called out in the behavior document I created is that when you remove the resource, no delete actually occurs. It's just removing management of the backup configuration. This may be slightly surprising to a user but It's probably an unlikely scenario to run into. A terraform removal looks like this in the CLI.

I think this is okay and is probably our best option here. A couple other approaches I could think of:

1. have backups disabled by default and have the lack of a resource indicate that they are disabled. This would mean that addition and removal of the config aligns with whether they are on or off. That seems undesirable because disabled by default is hostile to the user.
2. have backup configuration be a setting on the cluster resource. In this case, we're not adding or removing a resource in terraform which correlates better to backup configuration always existing. This is a potentially viable option and may be more natural for a user. The 2 main drawbacks here are 1. The cluster resource is quite complex already 2. I didn't consider this before the existing approach so migrating to the other approach would be more effort.

[fantapop]

2. have backup configuration be a setting on the cluster resource. In this case, we're not adding or removing a resource in terraform which correlates better to backup configuration always existing. This is a potentially viable option and may be more natural for a user. The 2 main drawbacks here are 1. The cluster resource is quite complex already 2. I didn't consider this before the existing approach so migrating to the other approach would be more effort.

I've decided to dedicate a couple hours to exploring this.

[fantapop]

closing in favor of #242