Make consul_keys behavior less surprising

[apparentlymart]

The consul_keys resource has a number of rough edges that make its behavior rather surprising. @phinze addressed a lot of its bugginess in a recent change, but its general design and implementation approach remained rather unusual.

In particular:

• Since @phinze's earlier bugfixes, the value attribute in the key blocks is not updated on refresh. This meant that Terraform does not notice "drift" in the configuration and show it in the plan, but the Update implementation secretly updates those changed keys anyway, leading to surprise and confusion.
• The delete attribute in key blocks applies only when the entire resource is removed, and not when individual key blocks are removed. This means the resource is able to add and update keys but not to remove keys.

The main driver for this change is to make delete work for individual key blocks, so removing a key block and applying has the expected effect of removing just that key from the store.

The implementation of this depends on using set difference to detect added and removed key blocks, which in turn required restoring the behavior of refreshing value so that Terraform would actually identify and fix differences in the underlying store. An unintended but positive side-effect of this implementation choice was fixing the first point above, so that Terraform will now report correctly in the plan that it intends to update the affected key.

In the process of implementing this I altered the implementation style to be what I'd consider a more "conventional" Terraform provider implementation, with separately-implemented Create and Update. However, that created a lot of code repetition and so I factored out the noise of interacting with the Consul API into a separate private client that is designed around Terraform's needs.

---

There are several confusing aspects of this resource that this PR does not address and, as far as I can tell, that can't be addressed without a breaking interface change:

• There is no way for Terraform to take ownership of a particular key prefix within the store, and then detect and remove errant keys that are not present in the configuration. (See consul_key_subtree resource #5211)
• The fact that the key blocks are implemented as a set rather than as a map (with path as the key) means that the resource still produces some rather confusing diffs in cases where the value of a particular key is being updated: rather than appearing as an update of the value field as you'd expect, it instead appears as a removal of an entire set member and the addition of another one with the same path.

I've intentionally not attempted to address these in this PR, but wanted to call them out.

[phinze]

First review of these changes looks good.

In #4787 the reason I pulled out the value update was to avoid spurious diffs when using default - does this revert that behavior or is there something to mitigate that here?

I'd like to get the consul provider nightly acctests spun up before we merge (something I've been meaning to do for a few weeks now).

[apparentlymart]

@phinze I am attempting to work around that diffing issue by updating value only when there's already a value, with the goal of then only updating the keys that are attempting to write to Consul, and ignoring the ones that are only reading. I'm assuming here that the "default" diffs are only an issue when we write back the default into the value attribute on an unsuccessful read.

Having the nightly acctests for Consul sounds great. (Kinda surprised that isn't already true since that sounds a lot easier than setting up the environment for AWS acctests! 😀)

[phinze]

Alrighty the consul nightlies are in place and I've given this another look - LGTM!

[ghost]

I'm going to lock this issue 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 similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.