Update manylinux detection to be robust to incompatible ABIs

[mayeut]

armv7l machine overlaps multiple ABI (armhf, armel). The same goes for i686 when running on x86_64 kernel (i686, x32).
This commit checks that ABI is compatible with the ones defined in PEP 513/571/599.
Partially addresses #217

[chrahunt]

This sets some groundwork for but doesn't fully address #217, since it does not add the corresponding platform tags. Cf pypa/pip#5391.

[brettcannon]

I don't know anything about the ELF format so I'm not in a good position to review this.

[mayeut]

This sets some groundwork for but doesn't fully address #217, since it does not add the corresponding platform tags.

I'm reluctant to add a new platform tag for x32 since it could break the current ecosystem (where I guess all tools relies on the platform tag being linux_i686). IMHO, the major issue is that, on x32 systems, i686 manylinux wheels are installed instead of using local cache (c.f. #160 also) or building from sources. This PR only prevents downloading i686 manylinux wheels on those systems.

That being said, if @pypa/packaging-committers want me to add a new platform tag, I will do so.

[brettcannon]

@mayeut if i686 wheels won't work on x32 then listing a more appropriate CPU architecture in the platform tag makes sense to me.

[chrahunt]

@mayeut if you just change the original comment to say "partially addresses #217" it's fine by me. :)

[mayeut]

@chrahunt, done.

[chrahunt]

Several minor comments. In general this approach looks good and is mostly in-line with the changes that were made in pypa/pip#7102.

[mayeut]

@chrahunt, sorry it took so long for me to be able to work on this. The new commit should answer all your remarks. I can squash the commit if need be.

[chrahunt]

Great! This is much easier to follow and will be easier to extend later if needed. Just one small comment, otherwise this looks good to me. Personally I would squash, but that's a decision that can also be made by whoever merges.

[mayeut]

I squashed all commits and added some more tests.

[chrahunt]

Looks good to me!

[mayeut]

CI failures are not related to the changes in this PR.

[aixtools]

CI failures are not related to the changes in this PR.

Glad someone else had a push do the same thing my PR did - and if you do not mind, I'll steal your comment.

Still do not understand how #243 ever passed.

[brettcannon]

@mayeut I think the failures are probably due to coverage 5.0 being released and tweaking its coverage results. I've opend #246 to track the need to fix this.

[di]

This looks ready to merge. @brettcannon Would you like a chance to review/approve before merging?

[brettcannon]

@brettcannon don't hold this PR up for my review; currently buried under other stuff.