Cardano Updates

This fixes builds for the dependencies haskell-language-server and
proto-lens.

proto-lens fails with:

    Error: [Cabal-6661]
    filepath wildcard 'proto-lens-imports/google/protobuf/descriptor.proto'
    refers to the directory 'proto-lens-imports/google/protobuf', which does not exist or is not a directory.
    filepath wildcard 'proto-lens-imports/google/protobuf/descriptor.proto'
    does not match any files.

However, SRP is currently required because the released version does not
support ghc-9.12.

The previous haskell-language-server did not support ghc-9.12, so we are
upgrading it to the latest version

The proto-lens source-repository-package build fails with:

    Error: [Cabal-6661]
    filepath wildcard 'proto-lens-imports/google/protobuf/descriptor.proto'
    refers to the directory 'proto-lens-imports/google/protobuf', which does not exist or is not a directory.
    filepath wildcard 'proto-lens-imports/google/protobuf/descriptor.proto'
    does not match any files.

However, SRP is currently required because the released version does not
support ghc-9.12.

This fixes the following static build errors resulting from updating
nixpkgs:

    (.text.use_builtin_flow+0x10): undefined reference to `pg_fe_cleanup_oauth_flow'
    collect2: error: ld returned 1 exit status

This works by removing curl support for postgresql and enabling static libraries
for liburing and snappy

Fixes https://github.com/IntersectMBO/cardano-db-sync/issues/2083

The `queryMinRefId` query uses
```sql
SELECT id FROM <table> WHERE <field> >= $1 ORDER BY id ASC LIMIT 1.
```

The planner sometimes picks a bad plan:

```sql
Index Scan using tx_pkey on tx
  Filter: (block_id >= $1)
```

the filter is not Index Cond, so this ends up in a sequential scan.
The index refers to the primary key and is only used for sorting.

Instead we use a simpler query without ORDER BY:

SELECT id FROM <table> WHERE <field> >= $1 LIMIT 10000
This forces the planner to use the field's index.
The results are fetched and the minimum is found in Haskell.
Near the tip this returns only a handful of rows.

If there are more than 10000 matching rows (large rollback),
we fall back to the original ORDER BY id ASC LIMIT 1 query.

Make sure we're using indexes during rollbacks 13.6.0.5

    Fixes https://github.com/IntersectMBO/cardano-db-sync/issues/2083

    The `queryMinRefId` query uses
    ```sql
    SELECT id FROM <table> WHERE <field> >= $1 ORDER BY id ASC LIMIT 1.
    ```

    The planner sometimes picks a bad plan:

    ```sql
    Index Scan using tx_pkey on tx
      Filter: (block_id >= $1)
    ```

    the filter is not Index Cond, so this ends up in a sequential scan.
    The index refers to the primary key and is only used for sorting.

    Instead we use a simpler query without ORDER BY:

    SELECT id FROM <table> WHERE <field> >= $1 LIMIT 10000
    This forces the planner to use the field's index.
    The results are fetched and the minimum is found in Haskell.
    Near the tip this returns only a handful of rows.

    If there are more than 10000 matching rows (large rollback),
    we fall back to the original ORDER BY id ASC LIMIT 1 query.

Fixes https://github.com/IntersectMBO/cardano-db-sync/issues/2083

The `queryMinRefId` query uses
```sql
SELECT id FROM <table> WHERE <field> >= $1 ORDER BY id ASC LIMIT 1.
```

The planner sometimes picks a bad plan:

```sql
Index Scan using tx_pkey on tx
  Filter: (block_id >= $1)
```

the filter is not Index Cond, so this ends up in a sequential scan.
The index refers to the primary key and is only used for sorting.

Instead we use a simpler query without ORDER BY:

SELECT id FROM <table> WHERE <field> >= $1 LIMIT 10000
This forces the planner to use the field's index.
The results are fetched and the minimum is found in Haskell.
Near the tip this returns only a handful of rows.

If there are more than 10000 matching rows (large rollback),
we fall back to the original ORDER BY id ASC LIMIT 1 query.

    Fixes https://github.com/IntersectMBO/cardano-db-sync/issues/2083#issuecomment-4110278201
    for 13.6.0.5.
    The planner sometimes uses a query similar to

    Index Scan using tx_pkey on tx
      Filter: (block_id >= $1)

    the filter is not Index Cond, so this ends up in a sequential scan.
    The index refers to the primary key and is only used for sorting.
    Instead we want to use

    Sort (top-N heapsort)
      -> Index Scan using idx_tx_block_id
           Index Cond: (block_id >= $1)

    With this change we're forcing a similar plan

    Aggregate
      -> Index Scan using idx_tx_block_id
           Index Cond: (block_id >= $1)

    making sure we're using the Index Cond and then sorting.

Fixes https://github.com/IntersectMBO/cardano-db-sync/issues/2083#issuecomment-4110278201
The planner sometimes uses a query similar to

Index Scan using tx_pkey on tx
  Filter: (block_id >= $1)

the filter is not Index Cond, so this ends up in a sequential scan.
The index refers to the primary key and is only used for sorting.
Instead we want to use

Sort (top-N heapsort)
  -> Index Scan using idx_tx_block_id
       Index Cond: (block_id >= $1)

With this change we're forcing a similar plan

Aggregate
  -> Index Scan using idx_tx_block_id
       Index Cond: (block_id >= $1)

making sure we're using the Index Cond and then sorting.