Stop using the database auto-increment ID

[josecelano]

@WarmBeer @da2ce7 @cgbosse and @josecelano were discussing the torrent IDs.

Discussion originated here: #146 (comment)

Context

We were using auto-increment IDs (generated by the database) for:

• Database relationships.
• When we want to reference a torrent on an URL, for example: GET /torrent/{id}

We've changed that for the API endpoints so now we use the infohash: GET /torrent/{infohash}

@josecelano proposed removing the IDs because that would make it easier to share data between indexes. For example:

• Importing data from another torrust tracker index.

That led to a broader discussion about how:

• We can transfer data increasing interoperability.
• If the infohash is a good ID for the database.
• If we should use a string to store the infohash or an integer, BLOB, etcetera.

First conclusions

• UUID (and, in this case infohash) can have a bad performance with big tables, so it seems the best option is to generate a secondary ID derived from the hash. but that leads to conflicts when you query the database. There can be two infohashes with the same "short" infohash.
• In the future we could have: infohashes V2, or even support for IPFS, so it seems the infohash is not a good idea.

Finally, the discussion ends up by changing the long-term vision about the index. HTe index could be, not a torrent v1 index, but a "decentralized multi-protocol context index" where you can find metadata about contexts which you can reach by using different locator mechanisms:

• BitTorrent protocol v1
• BitTorrent protocol v2
• IPFS

So what you really index is the metadata about the content. We call that an "index entry". The index entry can have multiple sets of related metadata, depending on who added that metadata for the contents. It would we quite the opposite. The index contains the description of the data we want to find and the metadata would be how you can find that content.

For the time being, we are not going to change the DB schema to use infohashes.