Create new types for service-defaults upstream cfg

[freddygv]

This PR expands service-defaults such that most upstream configuration can be configured centrally. There is a map called upstream_configs keyed on <optional-namespace/>service-name which provides per-upstream configuration. There is also an upstream_defaults object for providing configuration that applies across all upstreams of the given service.

The fields in both of these were promoted out of the opaque config map in Upstream so that they can be validated on config write. Note that calls to ResolveServiceConfig will return them in the existing opaque map so that clients on older versions can receive the new centrally-configured fields.

Below is an example config entry:

kind = "service-defaults"
name = "web"

connect {
  # These apply to the upstream key and override the value from upstream_defaults
  upstream_configs {
    "redis" {
      passive_health_check {
        max_failures = 3
        interval = "5s"
      }
    }

    "finance/billing" {
      mesh_gateway {
        mode = "remote"
      }
    }
  }
  
  # These defaults apply across all upstreams of web
  upstream_defaults {
    connect_timeout_ms = 10000
  }
}

In general this is the merge order for something like "protocol" for an upstream listener:

• proxy-defaults.Config["protocol"]
• service-defaults of the upstream
• service-defaults.upstream_defaults of the downstream
• service-defaults.upstream_configs of the downstream for the upstream
• Local upstream configuration (Proxy.Upstreams[i].Config["protocol"])

---

TODO:

• Fixup some tests
• Docs changes
• Changelog

[rboyer]

I think if you can rearrange things so the config flattening RPC doesn't need to know about nodes that'll be a big improvement. The only other substantial concern here was about some missing api and structs json omitempty struct tags and some possible merging problems down the line.

[rboyer]

LGTM

[markan]

One minor suggestion around readability, but otherwise this looks good.

[markan]

I wonder if it might make sense to split this function out and apart.
With big closures like this can be hard to reason about what is captured from the surrounding context; splitting it into a small closure that calls another function makes that explicit.
There's also quite a bit of code, and a number of separate concerns; for example figuring out the default protocol is spread around a bit.

[freddygv]

That is a good point. I added a TODO here that I can take care of for the beta.

[hashicorp-ci]

🍒 If backport labels were added before merging, cherry-picking will start automatically.

To retroactively trigger a backport after merging, add backport labels and re-run https://circleci.com/gh/hashicorp/consul/339293.