Add support for znver1 and znver1_32 architectures

[Conan-Kudo]

OpenMandriva offers a Ryzen-optimized variant of the distribution, so libdnf needs to understand this architecture on OpenMandriva.

Depends on the following PRs:

• Add znver1 arches with 32-bit + 64-bit variants and proper CPU detection rpm#1035
• Add support for znver1 and znver1_32 architectures openSUSE/libsolv#365

[m-blaha]

Looks like modularity on ryzen machine (I do not have such a hardware, I just tweaked is_ryzen() to return always true) started to misbehave:

$ dnf module list
Modular dependency problems:

 Problem 1: nothing provides requested module(stratis:1:3020190306064421)
 Problem 2: nothing provides requested module(standard-test-roles:3.0:3020190319161255)
 Problem 3: nothing provides requested module(scala:2.10:20180702155503)
 Problem 4: nothing provides requested module(rpick:latest:3020190313083345)
.
.
.

@j-mracek isn't it possible that modularity uses arch (which is now znver1on ryzen) instead of base_arch to compute dependencies?

[j-mracek]

I have a bad news. DNF/LIBDNF uses arch (not basearch) for creation for the sack and modular sack. Therefore the change in detection requires change in dnf (dnf.rpm._BASEARCH_MAP), rpm and libsolv. DNF uses basearch only for downloading of repositories and for comps.

[m-blaha]

True:

# dnf install acpi
Error: 
 Problem: conflicting requests
  - package acpi-1.7-11.fc30.x86_64 does not have a compatible architecture

[Conan-Kudo]

@m-blaha @j-mracek Wait, shouldn't this work once the rpm PR lands? We make znver1 descend from x86_64, so it's considered a superset and x86_64 packages are compatible...

[j-mracek]

It means that the PR must require future rpm and libsolv with required change. Therefore we have to wait till rpm and libsolv accept the change and release it. Libsolv will wait till rpm accept it.