Automate f-droid releases

I think we should take care of this now, otherwise we'll never do it and it will be annoying every time. We currently need to submit f-droid builds manually. There is an opportunity to automate it based on tag updates, but our files aren't ready for this because it uses regex. I think we have two options:

1) Adjust build files to a regexable format

• Set https://f-droid.org/docs/Build_Metadata_Reference/#AutoUpdateMode to enable auto updates
• Set https://f-droid.org/docs/Build_Metadata_Reference/#UpdateCheckMode to Tags and add the appropriate tag pattern
• Set https://f-droid.org/docs/Build_Metadata_Reference/#UpdateCheckData to read from either the respective build.gradle.kts, or a separate version.txt file.
• Adjust our CI especially release process so that version.txt or build.gradle.kts is correctly adjusted.

Upside here is that it is all automated, we adjust our version files once and then f-droid does the rest. Downside is that once we tag (which is early), f-droid will pick it up, so we have no way to hold a build. We should make sure that the regex is fairly stable, so that we don't accidentally break this by changing something in build.gradle.kts and it maybe picks up the wrong version.

2) Add a build step after publish_hold that will send a pull request to f-droid

• Add a step that checks out fdroiddata, updates the yml files, makes sure their linters pass
• Create a pull request such as https://gitlab.com/fdroid/fdroiddata/-/merge_requests/24167

Upside is that we do it after the publish_hold step and it is similar to the play store review. Downside is they have to manually review each pull request.

3) Defer tagging in our builds until after publish_hold

• Make it so that tagging only actually happens after the publish_hold is confirmed
• Continue same steps as in (1)

Upside is that we can hold builds also for those who use FFUpdater or similar. The build is only considered a release once the publish step completes. We get the upsides from (1) as well. The only downside is that this is more effort since we're making some major adjustments to our release process.

Start by comparing the F-Droid Build Metadata Reference with the current build.gradle.kts and release process around publish_hold. Evaluate the three proposed approaches, including tag patterns, version.txt or build.gradle.kts updates, and fdroiddata pull requests. Done means F-Droid builds are automated while the project can still control when releases become available.