Pin pg_repack version 1.5.2 based on tag

[za-arthur]

What kind of change does this PR introduce?

• upgrade pg_repack from 85b64c6d4f599b2988343c4e7121acab505c9006 to ver_1.5.2.

Additional context

New pg_repack version was released and it is possible to use tag instead of the commit id:
https://github.com/reorg/pg_repack/releases/tag/ver_1.5.2

Commit id was pinned before because the version wasn't released yet:
#1314

Action Items

• New extension releases were Checked for any breaking changes
• Extensions compatibility Checked
  • Proceed to extensions compatibility testing, mark as done after everything is completed
• Backup and Restore Checked
  • Proceed to backup testing while extensions are enabled
    • After every restore, re-run the tests specified at point 3.1

Since pg_repack doesn't have persistent metadata it might be not necessary to run Backup and Restore test.

Extensions compatibility testing

1. Enable every extension
   1. Check Postgres’ log output for any error messages while doing so
      1. This might unearth incompatibilities due to unsupported internal functions, missing libraries, or missing permissions
2. Disable every extension
   1. Check Postgres’ log output for any cleanup-related error messages
3. Re-enable each extension
   1. Run basic tests against the features they offer, e.g.:
      1. pg_net - execute HTTP requests
      2. pg_graphql - execute queries and mutations
      3. …to be filled in

Backup Testing

Follow the testing steps steps for all the following cases:

• Pause on new Postgres version, restore on new Postgres version
• Pause on older Postgres version, restore on new Postgres version
• Run a single-file backup backup, restore the backup

Testing steps

1. Generate dummy data
   • the ‘Countries’ or ‘Slack clone’ SQL editor snippets are decent datasets to work with, albeit limited
2. Save a db stats snapshot file
   • Do this by running supa db-stats gather -p <project_ref>
3. Backup the database, through pausing the project, or otherwise
4. Restore the backup, through unpausing the project or cli
5. Check the data has been recovered successfully
   1. Visual checks/navigating through the tables works
   2. Run supa db-stats verify against the project and the previously saved file

[pashkinelfe]

Most if not all the other extensions use commit id for inclusion, not release tag. I'd try to avoid changing semantics for pg_repack only.

[samrose]

@pashkinelfe It is kind of a mixed bag now, for what it's worth. We pin it depending on what is best/most convenient for the given source repo. Some are specific commit hashes (especially from source repos that don't have release tags), and some are tags. So it is ok if someone changes it to a branch, because there will still be a specific sha 256 hash. as long as people are making sure they are getting the version of source they desire. Going forward we could start to consolidate on git commit hash to keep it uniform and that is fine with me.

[za-arthur]

I think it is fine to use tags instead of commit ids, when it is possible and when repos provide tags. It makes configs more clear and shows better intended version.

[samrose]

Fine with me fwiw @za-arthur