Refactor order of repos for sles15sp1

[ktsamis]

We had now the case of sles15o which went from LTSS to EOL and the repos didn't pass GPG validation. The build service extended the key's valid date but only for basesystem repo. The order that the repos are added is important because if basesystem is not the first one added the GPG signature is not verified. We renamed for sles15o the module_server_applications_pool_repo to server_applications_pool_repo because zypper adds the repos alphabetically and s now comes after os_pool_repo and os_update_repo. The os_pool_repo needs to be the first one added. We add repos in 2 stages: 1. cloud-init and repos defined here in user_data.yaml and then 2.in salt . We need to make sure that repos are consistent across both stages and the order is the correct one. We will have the same situation in sles15sp1 when it leaves LTSS and we should make sure that for all SPs the order and the naming are consistent.

[srbarrios]

In addition, we should not rely only in the zypper refresh made during the cloud-init phase. As we or our users might deploy environments that will stay for a long period.
If the GPG key expires on this long running machine, the zypper refresh will fail on this scenario, as the order of the repositories once is full deployed is wrong.