feat: Start supporting magnet upload

[angrynode]

Only parsing of the magnet upload is supported yet.

TODO:

• Create magnet table in DB with migration
• Save magnet in DB

In a future PR:

• Create torrent table in DB
• Start background task to resolve magnets
• Save resolved magnets in the torrents table

[angrynode]

This is very basic right now only a "successfully imported" page, plus a list, and upload form. Maybe the success page is completely useless and can be removed.

Right now nothing is done with the magnets we're just storing them in the DB.

Feedback welcome @Gabatxo1312

[Gabatxo1312]

@angrynode I think you can merge this PR !

[angrynode]

We may want to still have a link to the magnet list (with a counter) so a user is not tempted to add one more magnet that has already been uploaded.

[angrynode]

• MagnetForm accepts Some(category) + Option<content_folder>
• the modal is added on the category page
• pending magnets are displayed on the content_folder/category views
• links in the magnet list view are corrected
• dedicated magnet upload page is removed

[angrynode]

OK the basic features are here. I'm not really happy with the implementation.

I feel like we have a lot of boilerplate due to separation of category / content_folder. I think we could make the FolderRequest (maybe rename it) a unified interface for this.

I'll try something along those lines.

[angrynode]

This file should be removed.

[angrynode]

This file should be removed.

[angrynode]

This should be changed to an actual TorrentFile so we don't have to perform additional checks. When the background resolver resolves the magnet, it just sets the torrent accordingly.

[angrynode]

Before rebasing or opening a new PR, time for some cleanup.

[angrynode]

What if the folder is changed from a category to another? It's better to have a single source of truth, the content folder ID.

[angrynode]

Ha no because the usecase was having a Magnet at the top of a category. So in this case we should either have a category ID, or a content folder ID. On the rust side this is a simple enum but how to represent it on seaorm ?

[angrynode]

For failing the forms we should have something like:

/// A template which contains a form which can fail.
pub trait FormTemplate: FallibleTemplate + Sized {
    type Form;

    fn with_form(&mut self, form: Self::Form);

    fn with_failed_form(&mut self, form: Self::Form, message: String) {
        self.with_form(form);
        self.with_optional_flash(OperationStatus::error_message(message));
    }
}