Use temporary storage for file exports on iOS

[frenzibyte]

Usually on iOS the user is explicitly asked where to store every exported file, storing exports permanently will clog up the user's phone storage. I've tried to approach this with as less changes as possible.

[peppy]

I don't understand why you've change it this way. Can you just add this at the single usage rather than making Storage nullable? (will allow the failing test to still work).

diff --git a/osu.Game/Database/LegacyExporter.cs b/osu.Game/Database/LegacyExporter.cs
index 193887765d..6f46122e86 100644
--- a/osu.Game/Database/LegacyExporter.cs
+++ b/osu.Game/Database/LegacyExporter.cs
@@ -3,7 +3,6 @@
 
 using System;
 using System.Collections.Generic;
-using System.Diagnostics;
 using System.IO;
 using System.Linq;
 using System.Threading;
@@ -42,14 +41,13 @@ public abstract class LegacyExporter<TModel>
         protected abstract string FileExtension { get; }
 
         protected readonly Storage UserFileStorage;
-        private readonly Storage? exportStorage;
+        private readonly Storage exportStorage;
 
         public Action<Notification>? PostNotification { get; set; }
 
         protected LegacyExporter(Storage storage)
         {
-            if (storage is OsuStorage osuStorage)
-                exportStorage = osuStorage.GetExportStorage();
+            exportStorage = (storage as OsuStorage)?.GetExportStorage() ?? storage.GetStorageForDirectory("exports");
 
             UserFileStorage = storage.GetStorageForDirectory(@"files");
         }
@@ -72,8 +70,6 @@ protected LegacyExporter(Storage storage)
         /// <param name="cancellationToken">A cancellation token.</param>
         public async Task ExportAsync(Live<TModel> model, CancellationToken cancellationToken = default)
         {
-            Debug.Assert(exportStorage != null);
-
             string itemFilename = model.PerformRead(s => GetFilename(s).GetValidFilename());
 
             if (itemFilename.Length > MAX_FILENAME_LENGTH - FileExtension.Length)

[frenzibyte]

I'm afraid being this lenient will end up having this silently break, that's why I got a little aggressive on the code there.

[peppy]

feel free to propose another direction

[frenzibyte]

I'm not sure I can think of anything else other than to change the constructor signature of every single exporter class to include a unique storage for "exports". The direction that I've went with here avoids that under the assumption that game data storage generally comes in the form of OsuStorage.

We can rename that class to UserDataStorage if it makes this read any better.

[peppy]

if you're going that far, make the constructors take an OsuStorage and updat all test usages to also provide one.

All seems too much to me for a failure that likely will never happen. I don't know what the silent break you're envisaging is.

[frenzibyte]

As I was writing about the probability of this breakage, I realised we can quite easily fix it by just publishing a hotfix that cleans up the exports folder at startup and call it a day. I will keep it weakly-typed.