Following my previous MR, this one yields another 30% in performance by replacing the nub in the guts of relatedComponents with the nub from Data.Discrimination, which is linear in computational time.

From my tests we go from this:

Tue Feb 27 09:08 2024 Time and Allocation Profiling Report  (Final)¬

   gargantext-phylo-profile +RTS -N -p -RTS¬

total time  =       51.89 secs   (192246 ticks @ 1000 us, 8 processors)¬
total alloc = 25,728,468,632 bytes  (excludes profiling overheads)¬

to this:

Tue Feb 27 09:22 2024 Time and Allocation Profiling Report  (Final)¬

   gargantext-phylo-profile +RTS -N -p -RTS¬

total time  =       37.03 secs   (137203 ticks @ 1000 us, 8 processors)¬
total alloc = 44,612,631,968 bytes  (excludes profiling overheads)¬

In numbers, this MR will make relatedComponents 30% faster. The total alloc goes up, but if that doesn't cause problems to the stability of the server, it shouldn't be a problem per se -- we are merely trading time for memory, which I guess is fair.

This MR also adds some tests for the relatedComponents, to serve as a base for regression testing if we decided to further optimise it.