Deal with duplicated MD5 in storages

[luizirber]

#648 unveiled a previous bug: since index save data to a location based on md5sum, what to do with files with potentially the same MD5 but different content?

This PR adds two files that match this case: both have empty k=21 scaled minhash sketches, and so have the same MD5 (despite coming from different datasets).

Note that FSStorage didn't check for duplicates, so it just overwrites the previous entry. This actually turns the tree into a DAG =]
ZipStorage triggers an error if entries are duplicated.

Solutions?

• Expand md5sum to take into account more data (for now it hashes ksize + each individual hash). This breaks all previous signatures.
• Storage.save takes a path argument, and return the path where the content was actually written. For FSStorage and ZipStorage it's the same, but for IPFSStorage it returns the IPFS hash, so... we can just change the path for the other storages too (MD5 + "_1", and so on), and this avoids creating duplicated entries. Since Storage.load takes what is returned from Storage.save when reading from a Storage, this is backwards-compatible, and is also correct (since it avoids the Tree-to-DAG problem).

Checklist

• Is it mergeable?
• make test Did it pass the tests?
• make coverage Is the new code covered?
• Did it change the command-line interface? Only additions are allowed
  without a major version increment. Changing file formats also requires a
  major version number increment.
• Was a spellchecker run on the source code and documentation after
  changes were made?

[codecov]

Codecov Report

Merging #994 into master will decrease coverage by 0.00%.
The diff coverage is 94.28%.

@@            Coverage Diff             @@
##           master     #994      +/-   ##
==========================================
- Coverage   92.23%   92.23%   -0.01%     
==========================================
  Files          72       72              
  Lines        5368     5393      +25     
==========================================
+ Hits         4951     4974      +23     
- Misses        417      419       +2     

Impacted Files	Coverage Δ
sourmash/sbt_storage.py	92.11% <94.28%> (-0.02%)	⬇️

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update ce48fe6...dc00792. Read the comment docs.

[luizirber]

I implemented the _n logic for ZipStorage, and checked that we are getting the right number of nodes saved. Now FSStorage is failing, because it only has 2 nodes, not the 3 required (1 internal, 2 leaves).

[luizirber]

Fixed FSStorage too, same logic from ZipStorage.

[luizirber]

Ready for review and merge @ctb

Possibly release this as 3.3.1 too, since it is annoying when it happens (it triggers after SBT is built, during saving)?