Sort bookmarked playlists

[GGAutomaton]

What is it?

• Bugfix (user facing)
• Feature (user facing)
• Codebase improvement (dev facing)
• Meta improvement to the project (dev facing)

Description of the changes in your PR

• Database migration
  Add a new column display_index (INTEGER NOT NULL DEFAULT 0) in playlists and remote_playlists.
• A playlists merge algorithm
  Implement an algorithm to merge local playlists and remote playlists by index. If they have the same index, sort them by name.
• Changing index
  If the index saved in the database doesn't match the actual display index for some reason (e.g., setting to all zero after database migration, or a new playlist is created with index -1 (thus being on the top), or the index is not continuous after deletion, or the user changes the index), save the new index to the database.
• Debounced saver
  Save the list 10 seconds after the last change occurred. The logic is almost the same as the one in LocalPlaylistFragment.
  Update: now the code is reused.
• UI and Item holder
  • Create list_playlist_bookmark_item.xml. It's just list_playlist_mini_item.xml adding an handle on the right.
  • Create LocalBookmarkPlaylistItemHolder and RemoteBookmarkPlaylistItemHolder.
  • LocalItemListAdapter will choose the item holder with/without the handle.

Before/After Screenshots/Screen Record

Before:

After:

After.mp4

Fixes the following issue(s)

• Fixes Sort bookmarked playlists in main page #3316
• Half of Manually reorder subscriptions lists #7870

APK testing

The APK can be found by going to the "Checks" tab below the title. On the left pane, click on "CI", scroll down to "artifacts" and click "app" to download the zip file which contains the debug APK of this PR.

Due diligence

• I read the contribution guidelines.

[GGAutomaton]

demo.mp4

The data storage logic has been modified, so more testing is required to avoid data loss.
I'm not familiar with rxjava, therefore some code needs extra checking.

[GGAutomaton]

Two of the three code smells are about high complexity methods. But their logic is continuous, I don't think refactoring them is a necessity.
Another warning is about the duplications of item touch callback. It might be ok if not reusing the code.

Please keep me informed if there's anything else to do.

[Stypox]

Thank you! I have a few comments

[sonarqubecloud]

SonarCloud Quality Gate failed.   

0 Bugs
0 Vulnerabilities
0 Security Hotspots
4 Code Smells

0.0% Coverage
3.7% Duplication

[Stypox]

Almost good, thank you! If you want me to take care of some of these changes, feel free to ask me ;-)

[Stypox]

The 5 sonartype issues are due to:

• some code duplication due to both BookmarkFragment and LocalPlaylistFragment allowing to move items around (but it would make things just more complicated to try to deduplicate this, it's not so much after all)
• an empty onComplete() method (there's no action to do, and there isn't a specific reason for this, so no need to add a comment to the method)
• some "commented out code" which is actually a legitimate comment explaining what methods should be used for future reference
• constructor with 8 parameters required by the Room database

I tested, fixed some things and made the implementation simpler. I tested again and everything seems to work well. I deleted, moved, renamed remote and local playlists and there were no inconsistencies.

[sonarqubecloud]

Quality Gate passed

Issues
5 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
1.6% Duplication on New Code

See analysis details on SonarCloud