neon extension did not get auto-upgraded

[skyzh]

Steps to reproduce

postgres=> \dx
                                            List of installed extensions
        Name        | Version |   Schema   |                              Description
--------------------+---------+------------+------------------------------------------------------------------------
 neon               | 1.1     | neon       | cloud storage for PostgreSQL
 pg_stat_statements | 1.10    | public     | track planning and execution statistics of all SQL statements executed
 plpgsql            | 1.0     | pg_catalog | PL/pgSQL procedural language
(3 rows)

postgres=> select * from neon_stat_file_cache;
ERROR:  relation "neon_stat_file_cache" does not exist
LINE 1: select * from neon_stat_file_cache;
                      ^
postgres=> select * from neon.neon_stat_file_cache;
ERROR:  relation "neon.neon_stat_file_cache" does not exist
LINE 1: select * from neon.neon_stat_file_cache;
                      ^
postgres=> alter extension neon update to '1.3';
ERROR:  must be owner of extension neon
postgres=>

Expected result

Upgraded to 1.3 on prod

Actual result

Stay at 1.1

Environment

Logs, links

[skyzh]

likely due to skip_catalog_updates. should include compute version into the compute spec.

[andreasscherbaum]

Stas: It affects cold start times if we upgrade the extension on every start.

Anastasia: Introduce flag if compute version changes, then roll upgrade.

[skyzh]

Will solve this specific problem by either introducing a new flag on the cloud side, or do an always-enabled migration on the compute side. The broader problem is tracked in #6936.