Switch DHCAST128 UAM to use libgcrypt

[NJRoadfan]

Switches the DHCAST128 UAM from WolfSSL+Nettle to libgcrypt for CAST encryption functions.

[rdmark]

I think we can remove the have_libgcrypt conditional and assume that this library is always available. Which we can safely do, since setup will fail early in the Meson script if libgcrypt cannot be detected.

[rdmark]

@demonfoo Heads-up that you may want to test compatibility with your AFP client with this change.

[demonfoo]

@rdmark I'd been considering reimplementing that based on libgcrypt, actually. I'll build it In a VM and try it out.

[demonfoo]

@rdmark I was able (with a bit of messing about) to get it building under my FreeBSD 13.4 VM. Forcing the DHCAST128 UAM succeeds (I've confirmed the DSO it installed is the new gcrypt-using one). The code appears to do the right things in all the relevant places.

[NJRoadfan]

Found some nagging meson issues when not using PAM since crypt.h wasn't being linked. Tested DHCAST128 with and without PAM and its working.

[NJRoadfan]

Fixed the change password function. Now a user can change their password.

[demonfoo]

I don't recall Apple's server implementations returning kFPAccessDenied when the password change was complete, but it does change the password.

Edit: Nevermind, that seems to be something local with PAM. Seems I'm getting stuff like:

Sep 21 16:13:14 freebsd afpd[35024]: in pam_sm_chauthtok(): pw_mkdb() failed

which doesn't seem to be anything specific to afpd.

[rdmark]

@demonfoo Thanks for testing!

[NJRoadfan]

@demonfoo I'm not seeing any PAM errors here.

[demonfoo]

@demonfoo I'm not seeing any PAM errors here.

It looks like this may be some kind of bug in FreeBSD's libutil. Running truss on the process shows its invocation of pwd_mkdb does work, but it looks like it's not waiting for the process correctly, and thus pw_mkdb() is returning -1 even though it shouldn't.

Edit: This is on FreeBSD 13.4-RELEASE/amd64 in a VirtualBox VM, if it matters.