Fix downloading/exporting when overwriting file would not truncate

[Stypox]

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

This PR adds a method to open a file and immediately truncate it: openAndTruncateStream(). Database and subscription exports previously did not truncate the file before writing to it, resulting in corrupted files like in #7802 when the new content is shorter than the previous content. I looked at how the Downloader interacts with files, but the downloader correctly sets the length of the file before writing to it, so I did not change anything there. I tested on my phone (Android 13 SAF) and on API 22 emulated (SAF and NNFP) and it worked in both.

Fixes the following issue(s)

• Fixes Cannot import from previous export #7802

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. You can find more info and a video demonstration on this wiki page.

Due diligence

• I read the contribution guidelines.

[TobiGr]

LGTM, but I'd love to see some comments explainig why the file needs to be truncated. Otherwise this fix might be removed by accident at a later point in time.

[TobiGr]

Test is failing:

> Task :app:testDebugUnitTest

ImportExportManagerTest > The settings must be exported successfully in the correct format FAILED
    java.lang.NullPointerException at ImportExportManagerTest.kt:59

[Stypox]

@TobiGr fixed, I just had to mock a different method in the test, now all tests pass. Also, I added the comments you requested.

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

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

See analysis details on SonarQube Cloud

[Stypox]

The SonarCloud analysis is wrong in this case, since the error is caught (and rethrown) to be able to properly close the stream, and every error should be caught, not just Exceptions.

[TobiGr]

I copied your comment to sonarcloud and marked the warning as false positive.