Flush logs before trimming to size.

There are situations where we may be hitting our SQLITE_BUSY timeout
when we go to trim. One possibility is that we may have a large ongoing
write when we go to trim.

So, this change just makes sure we're caught up before we go to trim,
which is the simplest thing we can do to address this. It's not a
foolproof solution though, so if we still see it crop up, we'll just
have to re-route all log operations through the single thread we have
setup in the PersistentLogger or something.

app/src/main/java/org/thoughtcrime/securesms/logsubmit/SubmitDebugLogRepository.java

@@ -104,6 +104,7 @@ public class SubmitDebugLogRepository {
 
   public void buildAndSubmitLog(@NonNull Callback<Optional<String>> callback) {
     SignalExecutors.UNBOUNDED.execute(() -> {
+      Log.blockUntilAllWritesFinished();
       LogDatabase.getInstance(context).trimToSize();
       callback.onResult(submitLogInternal(System.currentTimeMillis(), getPrefixLogLinesInternal(), Tracer.getInstance().serialize()));
     });

app/src/main/java/org/thoughtcrime/securesms/logsubmit/SubmitDebugLogViewModel.java

@@ -8,6 +8,7 @@ import androidx.lifecycle.ViewModel;
 import androidx.lifecycle.ViewModelProvider;
 
 import org.signal.core.util.ThreadUtil;
+import org.signal.core.util.logging.Log;
 import org.signal.core.util.tracing.Tracer;
 import org.signal.paging.PagedData;
 import org.signal.paging.PagingConfig;
@@ -43,6 +44,7 @@ public class SubmitDebugLogViewModel extends ViewModel {
     repo.getPrefixLogLines(staticLines -> {
       this.staticLines.addAll(staticLines);
 
+      Log.blockUntilAllWritesFinished();
       LogDatabase.getInstance(ApplicationDependencies.getApplication()).trimToSize();
 
       LogDataSource dataSource = new LogDataSource(ApplicationDependencies.getApplication(), staticLines, firstViewTime);