Bug 2238854

This is a follow-on from https://bugzilla.redhat.com/show_bug.cgi?id=2236343 . In current Rawhide, AFAICT, gnome-initial-setup is doing "the right thing", but there's still a problem, so setting this to anaconda.

When we install in Russian, using the web UI flow, on the installed system, the console keyboard layout is set to "us". This isn't right. It should be "ru".

Reproducible: Always

Steps to Reproduce:
1. Boot a current Rawhide Workstation live image.
2. Set the locale to Russia on the first g-i-s page.
3. On the second g-i-s page, confirm the keyboard layout is set to Russian.
4. Proceed to the third page. Note that the currently set layout is "us", but "ru" is available as the second option (this is correct).
5. Proceed to the installer and install the system.
6. Boot to the installed system. Note that, again, both "us" and "ru" layouts are available, with "us" as the default.
7. Go to a console, type some characters (you should see Latin characters), then press ctrl+shift and type some more characters. Also check the contents of /etc/vconsole.conf
Actual Results:  
Hitting ctrl+shift does not switch to inputting Cyrillic characters, and /etc/vconsole.conf says KEYMAP="us".

Expected Results:  
Hitting ctrl+shift at the console should switch to inputting Cyrillic characters, and /etc/vconsole.conf should say KEYMAP="ru".

anaconda has some very careful handling of this stuff in pyanaconda/keyboard.py `set_x_keyboard_defaults`. Note especially the block under the comment that starts "the console layout configured should be "native" by default".

However...we don't hit that code at all on the webUI flow. We instead hit the new code in pyanaconda/modules/localization/live_keyboard.py . What this code winds up doing is just asking localed to convert the *single currently active* xkb layout to a kbd layout.

So if you happen to have the 'ru' layout selected whenever this code is hit, I guess, you'll get the 'ru' console layout. But that is not the usual case. People installing in Russian - and other similar languages affected by this class of issues - will usually have 'us' selected in the installer (even if we *don't* make it the default, they will likely switch to it if they need to type anything), because they generally need to type Latin characters in the installer. But this doesn't mean they want "us" as their console layout!

In other words, the assumption jkonecny put in the commit message for this code - "Look for currently used keyboard layout and set that as virtual console keymap after conversion. It's probably what user wants to use because it was used during the installation." - is just not correct. Because of the difference between how layout switching works in kbd and xkb, you cannot assume that the currently-active xkb layout is the layout the user wants on the console.