Bug 1504229

Description of problem:
We have recently enabled RHUI with the ability to sync minor release repositories for customers, which has begun to be utilized.

There is one primary issue with this that was missed, which is that there is manual configuration required on the clients in order to set the release which the client will consume (so that it can see the actual repository data).

Proposal is to provide a shell script with the client-bootstrap which can simply read and set the releasever using the /etc/yum/vars method, and report on what is currently set.

Version-Release number of selected component (if applicable):
RHUI 2 + 3

How reproducible:
100%

Steps to Reproduce:
1. Sync a non xServer release for any RHEL based repository.
2. Connect a client with client certs.
3. Attempt to install packages from non-xServer repository.

Actual results:
Receive 404's as the client will try to get 7Server for example instead of 7.2 content, as the $releasever is not set on the client.

Expected results:
Need a simple method of dictating $releasever on clients that can be delivered with the client-bootstrap.

Additional info:
This was not a requirement until we began offering the minor-release repositories to be synced. We can set the release with subscription-manager, but this requires the system to be registered and that data is recorded at the registration endpoint. Since we do not utilize subscription-manager in the process of utilizing RHUI as a content-endpoint, we need to provide a simple scripted way of setting release on clients.

This can currently be worked around on a per client basis by creating a releasever file in /etc/yum/vars which contains the version we need (for ex, 7.2). There are no other contents need inside this file. This will set the $releasever to be used by yum and the rh-cloud.repo file, since we reference the variable for content location within that file.

Since customers are already making use of these minor release repos in a valid way (RHEL for SAP EUS 7.2, for instance), it seems most logical to simplify the process of setting releasever on the clients by providing tooling rather than documenting that they need to manually create and deploy these override files.