Speed up "Saving Application Details" part of repo update
Fixes 506.
This does the thing mentioned in 506 (renaming temp table, rather than copying data). In the process, I also identified that the temp tables were missing key indexes which slowed the process down. This fix took the update time from ~100 seconds to ~60 seconds on my Nexus 4.
Below are a couple of log cats from before and after the change (this logging is not part of this MR, it was just for diagnosing the problem).
*Before change:*
```
AppProvider D Calculating whether apps are compatible, based on whether any of their apks are compatible
D Update compatible flags took 20244ms
D Calculating suggested versions for all apps which specify an upstream version code.
D Update suggested from upstream took 17808ms
D Calculating suggested versions for all apps which don't specify an upstream version code.
D Update suggested from latest took 129ms
AppProvider D Update icon URLs took 7879ms
UpdateService I Updating repo(s) complete, took 104 seconds to complete.
```
*After change:*
```
AppProvider D Calculating whether apps are compatible, based on whether any of their apks are compatible
D Update compatible flags took 1047ms
D Calculating suggested versions for all apps which specify an upstream version code.
D Update suggested from upstream took 601ms
D Calculating suggested versions for all apps which don't specify an upstream version code.
D Update suggested from latest took 136ms
D Update icon URLs took 887ms
UpdateService I Updating repo(s) complete, took 63 seconds to complete.
```
See merge request !179
The idnexes which are added are for those columns which
are used to calculate information such as latest upstream version.
These queries use subqueries which seemed to be adversely
impacted by the lack of indexes.
In total, reduced update time on test device from just over 100 seconds
to just over 60 seconds.
This requires renaming the old app/apk tables to be deleted and
the temp ones to be renamed. This is done in a transaction to
ensure we always have at least `fdroid_app` and `fdroid_apk`.
Well, two transactions, one for renaming the `fdroid_app` table
and one for `fdroid_apk`.
Translators:
agilob Polish
Ajeje Brazorf Sardinian
Alberto Moshpirit Spanish
Daniil Stryukov Ukrainian
Enol Puente Asturian
Jaroslav Lichtblau Czech
Ldm Public French
lucnsy Chinese (China)
Marcelo Santana Portuguese (Brazil)
Mladen Pejaković Serbian
naofum Japanese
relan Russian
Fix 324 : Out of memory errors while updating repos.
Fixes#324, but in the process makes the updater take a lot longer. My benchmarks tell me that an update which used to take approx 30 seconds on my Nexus 4 now takes about 50-55 seconds. This is because it first inserts the apps into the database (in a temp table) and then subsequently copies that table to the actual table. This means there is a lot more disk access than before.
I'm open for discussion on whether this tradeoff is worth it - however I'll caution that there is always going to be a tradeoff between faster and more memory vs slower and less memory. This is the case with all software, and perhaps more so with memory constrained devices such as phones. Also, as the repo index grows (until perhaps we are able to extract the app descriptions in the future), this will become more of an issue.
I'd also like this to be CR'ed properly before merging, because it changes some important code around the repo updater. It is important because security, and it is also important because it is the main thing that F-Droid needs to do (get a list of apps to show the user).
See merge request !173
Translators:
ageru French
Ajeje Brazorf Sardinian
Alberto Moshpirit Spanish
enolp Asturian
Ldm Public French
lucnsy Chinese (China)
Mladen Pejaković Serbian
naofum Japanese
Will also appear as indeterminate if:
* The repo being downloaded from doesn't send a Content-Length header.
* While connecting to the HTTP server to begin downloading.
