libmd, kern, stand: consolidate md5 implementations (NFC)

[kevans]

Summary

Reduce the number of md5c.c between the three of these from two to one
by just reaching into the kernel build for both userland builds. The
precedent for this already exists for sha2 in both cases.

_libmd_ symbol privatization bits have been moved to sys/md5.h and
md5.h remains to #include <sys/md5.h> for compatibility.

This stops exporting MD5Pad() in the process because the kernel stopped
exporting it in 502a35d60f4c. soversion is bumped accordingly.

[emaste]

Interesting, there are many other copies of libmd around (other BSDs, embedded in various software) that include MD5Pad, but checking Debian Code Search I see (unsurprisingly) no users. I am a little torn as our shlib guidelines desire avoiding version bumps, but it would also be silly to restore MD5Pad just to satisfy that.

[kevans]

In D34497#781737, @emaste wrote:

Interesting, there are many other copies of libmd around (other BSDs, embedded in various software) that include MD5Pad, but checking Debian Code Search I see (unsurprisingly) no users. I am a little torn as our shlib guidelines desire avoiding version bumps, but it would also be silly to restore MD5Pad just to satisfy that.

Yeah; I did a couple other things later in the stack to try and help justify it, as well. I think the *Transform symbols are in the same boat and they keep causing problems with various compiler/linker/flag combos because the implementation symbols should be exported as well.

[allanjude]

Reviewed by: allanjude

[imp]

ObsoleteFiles.inc

56

Is there a reason this library isn't versioned?

sys/kern/md5c.c

133

These shouldn't have spaces, if you're changing anyway...

[emaste]

ObsoleteFiles.inc

56

It is, but a function is being removed

sys/kern/md5c.c

133

should probably do a style/K&R pass over this whole file first

[kevans]

ObsoleteFiles.inc

56

There's a later change in this stack that introduces symbol versioning