Comparing MD5s as UUIDs does not work anyway: it improperly slices and then compares the values, since our code always renders UUIDs as abcdabcd-abcd-abcd-abcd-abcdabcdabcd, always dashed and lower-cased, while the actual value stored in MD5 (i.e. string) PKs can be uppercased and typically non-dashed (e.g. ABCDABCDABCDABCDABCDABCDABCDABCD). As a result, all such MD5 PKs go into one pseudo-UUID range, usually the first one (because in ASCII & UTF-8, uppercase is lesser than lowercase letters).

The root cause is that Python's UUID can parse even such values:

In [3]: from hashlib import md5
In [8]: s=md5(b'hello').hexdigest()

In [9]: s
Out[9]: '5d41402abc4b2a76b9719d911017c592'

In [10]: from uuid import uuid4, UUID
In [11]: UUID(s)
Out[11]: UUID('5d41402a-bc4b-2a76-b971-9d911017c592')

This PR excludes MD5s and other UUID-like textual PKs from UUID detection.

As an extra change (separate commits), this PR also preserves the information on how the database presents the UUIDs — either lowercased or uppercased, and renders the actual sliced UUID values accordingly. This does not matter for native UUIDs (stored & compared as numbers), but does matter for UUIDs stored and/or compared as strings (at least from one side of the diff).