fix: Wrong infohash when info dict contains source field

[josecelano]

When you define a "source" field value in the "info" dictionary inside the torrent file, that field changes the torrent infohash value. We did not save that field in the database and in the in-memory struct TorrentInfo, so the calculated infohash was wrong because this field belongs to the info key.

This PR adds the missing field.

TODO

• Test with MySQL
• Update the documentation about how infohashes are calculated

Improvements

• Add tests for the infohash calculation with different examples of TorrentInfo values.
• The TorrentInfo struct should be explicit about the two types of torrents: single file or multiple file. See:
  https://wiki.theory.org/BitTorrentSpecification#Info_in_Single_File_Mode

Other considerations

I have not found any BEP describing this source key in the info dictionary. There could be more non-official fields. Maybe instead of adding a hardcoded field in the torrust_torrent table, we should add a json value or something that allows us to save all the extra non-official fields, but I have not seen any other. What do you think @da2ce7?

Extra

Info dict key with a single file:

{
      "length": 172204,
      "name": "mandelbrot_2048x2048.png",
      "piece length": 16384,
      "pieces": "<hex>7D 91 71 0D 9D 4D BA 88 9B 54 20 54 D5 26 72 8D 5A 86 3F E1 21 DF 77 C7 F7 BB 6C 77 96 21 66 25 38 C5 D9 CD AB 8B 08 EF 8C 24 9B B2 F5 C4 CD 2A DF 0B C0 0C F0 AD DF 72 90 E5 B6 41 4C 23 6C 47 9B 8E 9F 46 AA 0C 0D 8E D1 97 FF EE 68 8B 5F 34 A3 87 D7 71 C5 A6 F9 8E 2E A6 31 7C BD F0 F9 E2 23 F9 CC 80 AF 54 00 04 F9 85 69 1C 77 89 C1 76 4E D6 AA BF 61 A6 C2 80 99 AB B6 5F 60 2F 40 A8 25 BE 32 A3 3D 9D 07 0C 79 68 98 D4 9D 63 49 AF 20 58 66 26 6F 98 6B 6D 32 34 CD 7D 08 15 5E 1A D0 00 09 57 AB 30 3B 20 60 C1 DC 12 87 D6 F3 E7 45 4F 70 67 09 36 31 55 F2 20 F6 6C A5 15 6F 2C 89 95 69 16 53 81 7D 31 F1 B6 BD 37 42 CC 11 0B B2 FC 2B 49 A5 85 B6 FC 76 74 44 93</hex>",
      "private": 1,
      "source": "Source"
   }

Info dict key with a multiple files:

{
      "files": [
         {
            "length": 37,
            "path": [
               "file-425ef9ca-014d-403f-8f15-3ece9e3fad38.txt"
            ]
         },
         {
            "length": 37,
            "path": [
               "file-deeafa50-2e25-4f38-bec0-92865ca6bb1d.txt"
            ]
         }
      ],
      "name": "dir-839a49f0-cabc-4efb-ad5f-b6fb15f8a467",
      "piece length": 16384,
      "pieces": "<hex>8E 47 18 74 52 8E 68 92 DD 86 66 F0 0B DD AD B1 08 DC 69 44</hex>",
      "private": 1,
      "source": "Source"
   }

[codecov-commenter]

Codecov Report

Merging #249 (bc04231) into develop (070aed8) will decrease coverage by 13.77%.
Report is 2 commits behind head on develop.
The diff coverage is 96.92%.

@@             Coverage Diff              @@
##           develop     #249       +/-   ##
============================================
- Coverage    58.36%   44.60%   -13.77%     
============================================
  Files          128       76       -52     
  Lines         7498     4085     -3413     
============================================
- Hits          4376     1822     -2554     
+ Misses        3122     2263      -859     

Flag	Coverage Δ
rust	?

Flags with carried forward coverage won't be shown. Click here to find out more.

Files Changed	Coverage Δ
src/databases/mysql.rs	0.00% <0.00%> (ø)
src/databases/sqlite.rs	23.61% <0.00%> (-2.06%)	⬇️
src/models/info_hash.rs	83.68% <ø> (-4.78%)	⬇️
src/models/torrent_file.rs	80.97% <100.00%> (+16.43%)	⬆️
src/services/torrent_file.rs	100.00% <100.00%> (ø)

... and 113 files with indirect coverage changes

📣 We’re building smart automated test selection to slash your CI/CD build times. Learn more

[josecelano]

ACK 8fe0955