melange considers packages which provide an absolute symlink as providing the target

[murraybd]

@smoser made a change to melange, #1662, which he believes introduced a regression that melange will follow an absolute symlink and consider the package as providing the target even though the package is not actually providing or vendoring the shared object.

When discussing the fix @jonjohnsonjr mentioned that we should do global melange scan to confirm the sensibility of the changes.

This issue manifests itself quite regularly in package build logs of packages in the following way:

solving "keyutils-libs" constraint:   keyutils-libs-1.6.3-r5.apk disqualified because keyutils-dev-1.6.3-r5.apk already provides so:libkeyutils.so.1
  keyutils-libs-1.6.3-r0.apk disqualified because keyutils-dev-1.6.3-r5.apk already provides so:libkeyutils.so.1
  keyutils-libs-1.6.3-r1.apk disqualified because keyutils-dev-1.6.3-r5.apk already provides so:libkeyutils.so.1
  keyutils-libs-1.6.3-r2.apk disqualified because keyutils-dev-1.6.3-r5.apk already provides so:libkeyutils.so.1
  keyutils-libs-1.6.3-r3.apk disqualified because keyutils-dev-1.6.3-r5.apk already provides so:libkeyutils.so.1
  keyutils-libs-1.6.3-r4.apk disqualified because keyutils-dev-1.6.3-r5.apk already provides so:libkeyutils.so.1
  keyutils-libs-1.6.3-r5.apk disqualified because keyutils-dev-1.6.3-r5.apk already provides so:libkeyutils.so.1

[sil2100]

I've seen a lot of these during my latest glibc Wolfi test-rebuild. I also saw it during my first test-rebuild 2 weeks ago, but much less frequent. Right now most of the builds failed due to this, while previously only a small set.
Is this caused by a race-condition? Since I get a feeling that sometimes I see it more and sometimes less?

Is there a workaround for this?

[imjasonh]

Related possible fix #1739