1. Proposed title of this feature request

Initial ClusterVersion channel discovery

2. What is the nature and description of the request?

When a Cincinnati request contains the version query parameter, and that version is known to Cincinnati and a member of any channel, include that version in the response graph returned to the client. Do not include additional update edges, unless both the source and target release belong to the requested channel (no change there; I'm just pointing out that I'm not suggesting any change to the response's edges).

3. Why does the customer need this? (List the business requirements here)

Currently, you can have situations where a 4.y.z release is in fast-4.y, but hasn't cooked into stable-4.y. During that time, folks who install in the default stable-4.y will get VersionNotFound errors.

With the proposal, a stable-4.y request would include the 4.y.z node, to allow fresh 4.y.z installs in stable-4.y to avoid VersionNotFound errors.

Folks who'd installed an older release but updated to 4.y.z via fast-4.y could also set their channel to stable-4.y without waiting for 4.y.z to cook into stable.  Also in this space, this tooling would help folks recover from "oops, I didn't mean to set that channel" mistakes by preserving in-cluster knowledge of the current version's channel-membership, even if the current channel isn't a part of that set.

In either case, they'd still have the same wait before actually getting updates into or out of that version, but the overall experience should be smoother and less alarming.

4. List any affected packages or components.

Some folks (ART's mirror tooling? OSD/ROSA ClusterImageSet tooling? Other?) might currently conflate "returned in a response to a ?channel=... request" as "belongs to that channel". Although I don't know if "belongs to that channel" is actually a thing with clear semantics. We don't require all nodes returned in Cincinnati responses to contain updates in that channel, and if folks have been using the Update Service to make installation choices, that's somewhat on them (see our very handwavy API docs and our decision to not track install-time issues OTA-815). But still, we don't want OSD/ROSA suggesting customers install candidate-channel prereleases as a result, and we'd want to go do the usual responsible-adult outreach before throwing the switch on anything like this.