This fix is to avoid overflow on the primary key, which defaults to a
sequence value of type `int`. We are using insert queries with ON
CONFLICT DO SOMETHING. These types of queries first try to insert the
row, hence they compute the next value in sequence. Even if we do not
actually insert any rows because of conflict.

With `user_repo_permissions` table this might become a problem, as can
be seen in
[#inc-209-fiverr-user-permission-sync-is-broken](https://sourcegraph.slack.com/archives/C058XNX78D8/p1684785371774189)

In general, on each permission sync, we do an [`INSERT INTO
user_repo_permissions VALUES ... ON CONFLICT DO UPDATE SET ...`
](https://sourcegraph.sourcegraph.com/github.com/sourcegraph/sourcegraph@main/-/blob/enterprise/internal/database/perms_store.go?L424).
This call potentially inserts thousands of rows. But since most of the
time it does not do anything, we needlessly increment the value of the
sequence for the primary key. This sequence value needs to be calculated
before the insert itself, which was not known to me before.

In general it might take ~30-90 days to hit this limit. This time might
be lower than that in case of huge instances.
Depending on how often we write to the DB and how many rows we try to
write on each permission sync. This also depends on how the permissions
are setup on the customer side, e.g. how many repos a user can access on
average.

Example - if we attempt to write 1000 rows every second to the database,
it results in `2147483647 / (1000 * 60 * 60 * 24) = 24.855` days. But in
most cases we write less, so it will take more time.

Switched to bigint for the primary key. My worst case calculation is,
that we try to write 1 million rows to the DB every second, which in
turn results in the following: `9223372036854775807 / (1000000 * 60 * 60
* 24 * 365) = 292471.2086` years. So we should never hit that limit
again.

We do not really care that the IDs are sparse, as we only use them to
have a primary key on the table.

Tested locally the SQL migration queries, going both up and down. Tested
locally the changes in the DB store as well. DB store change is also
covered by unit tests already. The part of the migration that resets the
primary key on all rows has been tested with a customer instance during
the incident.

Even if we lose all the data in the `user_repo_permissions` table, it's
not a complete tragedy since we automatically recover by filling the
data periodically in again.

(cherry picked from commit e423a65)

## Description

backport #52299 to 5.0

I needed to change the parent of the migration in metadata.yaml and
there was a bazel conflict. I did it manually, not sure if there's a
better process for it...

## Test plan

Tested locally that it still builds...