Deprecate ubsec(4) for FreeBSD 13.0.

[jhb]

Summary

With the removal of in-tree consumers of DES, Triple DES, and
MD5-HMAC, the only algorithm this driver still supports is
SHA1-HMAC. This is not very useful as a standalone algorithm
(e.g. IPsec only uses SHA1-HMAC in combination with AES-CBC).

Test Plan

• amd64 GENERIC build

[jhb]

Some of these cards also have a PRNG, but given RDRAND on most(?) modern x86 CPUs, that doesn't seem worth keeping this driver around for either.

[cem]

SHA1-HMAC is not completely obsolete, but I don't know how old this hardware is / how extensively it is used. If nothing would use the acceleration (even OpenSSL?), sure, kill it. I guess the gone_in() gives us time to find out if there are still users of accelerated SHA1-HMAC. (I'd guess anything with AESNI SHA extensions is probably faster than this?)

[jhb]

OpenSSL's engine doesn't use plain digests since we don't let you do it piecemeal via /dev/crypto, and even when OpenSSL does, it doesn't offload HMAC, but just the plain digests like SHA1, etc. The only in-kernel configuration that would use SHA1 HMAC is if someone ran IPsec with AH only (so on encryption, only auth) with SHA1 (geli requires a cipher, and even if I add TLS 1.0/1.1 it will require AES-CBC). It's not impossible, but seems highly unlikely. The alternative is that I have to gut much of this driver when I remove DES. I guess it also supports the async stuff, but that also isn't used by anything (modern OpenSSL doesn't try to use it because it isn't documented). The newest part (BCM5825) supported by the current driver was released in 2005. There is a newer OpenBSD driver that adds AES-CBC support, but not AES-CTR. If someone really has the hardware, I've at least converted the driver to the new framework as a starting point they can dig out of SCM.

[cem]

You had me at 2005. Let it burn.