The history of this is that #974 identified a problem, which was fixed
in !497. That MR added test coverage for the bug.
However, the fix for it actually added a huge performance hit, on the
order of 30 seconds or so when calculating the suggested version.
This fixes that performance problem by removing the need for a sub
query. The end goal is to take the following query:
```
UPDATE app
SET suggestedVersion = (
SELECT MAX(apk.version)
FROM apk
WHERE ...
)
```
and the `WHERE` clause needs to somehow join the outer `app` table with
the inner `apk` table, such that the repo in question does not matter.
It can't just join directly from `apk.appId -> app.rowid`, because the
`app` is specific to a given repository, but we want to select the
`MAX(apk.version)` from every related apk, regardless of repo.
This commit solves it by joining the inner `apk` table onto an
intermediate `app` table, which is used purely so that we can select
apks where their `packageId` is the same as the `packageId` of the app
being updated.
aae0a57dfe