Add an EnvironmentFile to suse-migration-prepare.service bsc#1199028

[KeithMnemonic]

This PR adds an EnvironmentFile entry to suse-migration-prepare.service that ensure running SUSEConnect as chroot still has access to /etc/sysconfig/proxy and be able to communicate via a proxy.

In addition, while testing this fix, an issue was found with how the suse-migration-pre-checks was being created. This lead to a conflict as both suse-migration-pre-checks and suse-migration-services contained python modules. When suse-migraton-services was installed, it complained about some python files already being installed. The best solution without creating new packages (suse-migration-services-common, for example ) was to leverage the existing spec file and have it create a "sub package" of suse-migration-pre-checks. This allows proper control of ensuring both packages are installing a unique set of python files.

The version was updated as this is needed for the Conflicts < 2.0.33 in case a customer installed the original 2.0.32 and then upgraded to 2.0.33 before doing the migration

[rtamalin]

Looks good to me

[KeithMnemonic]

Tested image fully and no conflicts installing all 3 packages

suse-migration-pre-checks-2.0.33-1.86.1.noarch.rpm
SLES15-Migration-2.0.33-57.x86_64.rpm
suse-migration-sle15-activation-2.0.33-6.43.1.noarch.rpm

the upgrade logs show no errors and the system has successfully booted to SLES-15-SP1. The units file contains the correct entries

migration@localhost:/etc/systemd/system/multi-user.target.wants> cat suse-migration-prepare.service
[Unit]
Description=Prepare For Migration
After=suse-migration-setup-host-network.service
Requires=suse-migration-mount-system.service suse-migration-setup-host-network.service network-online.target

[Service]
Type=oneshot
EnvironmentFile=-/etc/sysconfig/proxy
ExecStart=/usr/bin/suse-migration-prepare

[Install]
WantedBy=multi-user.target