Refine oem config for our installiso x86_64 profile

[phillxnet]

Given a recently noticed change in behaviour in our kiwi-ng upstream (#118) and some relatively recent fixes in the available options regarding oem configuration (see upstream: OSInside/kiwi#2055), it is proposed that we enable the newly functional auto-reboot capability so that the first boot of our installed image is not via the recently dysfunctional kexec function (#118), but via the following config option:

<oem-reboot>true</oem-reboot>

Used within our existing section.

This proposal should remove any potential discrepancy between our users first boot and all subsequent boots. But it may hamper diagnosis of such issues as for example: #82 where a manual grub re-install could be effected; where as if we immidiately reboot into our freshly transferred image and it fails to boot, there is little obvious recourse/resource. However any boot failures are discovered far more immediately, which may aid in speeding up consequent re-install attempts: given the tester is not required to await the kexec completion and complete the jeos-first boot setup thereafter and the consequent slightly long first initialisation of the rockstor servcies before then being able to test for successful reboot (read install) completion regarding the initial boot.

A Reference for the above proposed addition is available here:
https://documentation.suse.com/kiwi/9/single-html/kiwi/index.html#oem-customize

[phillxnet]

I am not yet inclined to go with the suggestion here. As is, our installers have a working system (the installer kexec-ed to the installed system) at least on first boot, with which to 'fix' some outstanding uefi boot issues that affect a suspected minority of systems. See issue #82 for details and a proof on a uefi only qemu config of our installed system booting in uefi.

If we go for this auto reboot directly after image transfer we risk loosing the only oportunity some target systems have of working around the currently observed failures.

We can watch upstream carefully for any uefi developments that may make this move a safer one. Ideally we need a reproducer system for #82 that can be used as an indicator of an upstream fix so that we can again re-consider this issues proposal.

[phillxnet]

Closing this issue as we don't appear to be requiring this. It was originally proposed, in part, as a work around for a bug that has since been resolved. And has since had little attention.

We can always re-open if need be.