joblib.hash calls fail on FIPS-140-mode RHEL systems

[bernstei]

RHEL (and clones, such as Rocky) can be put in FIPS mode, which restricts non-FIPS-140 compliant cryptographic settings. This, it turns out, includes md5 hashes, and it's apparently disabled some very low level, so calls to joblib.hash() in umap_.py lead to errors like

  File "/home/cluster/bernstei/.local/lib/python3.9/site-packages/umap/umap_.py", line 2822, in fit                              
    self._input_hash = joblib.hash(self._raw_data)
  File "/home/Software/python/system/extra/lib/python3.9/site-packages/joblib/hashing.py", line 263, in hash                     
    hasher = NumpyHasher(hash_name=hash_name, coerce_mmap=coerce_mmap)                                                           
  File "/home/Software/python/system/extra/lib/python3.9/site-packages/joblib/hashing.py", line 169, in __init__                 
    Hasher.__init__(self, hash_name=hash_name)
  File "/home/Software/python/system/extra/lib/python3.9/site-packages/joblib/hashing.py", line 59, in __init__                  
    self._hash = hashlib.new(hash_name)
  File "/usr/lib64/python3.9/hashlib.py", line 170, in __hash_new                                                                
    return __get_builtin_constructor(name)(data)
  File "/usr/lib64/python3.9/hashlib.py", line 86, in __get_builtin_constructor                                                  
    raise ValueError('unsupported hash type ' + name + '(in FIPS mode)')                                                         
ValueError: unsupported hash type md5(in FIPS mode)

Using joblib.hash(..., hash_name="sha1") appears to be sufficient to fix it, but I really don't know what you'd consider a good mechanism for controlling this at the umap level, or even whether you think it's an important enough use case to be worth addressing.