GPKG status performance regression fix

[rcoup]

Description

Workaround for a GPKG performance regression introduced in b20eec4.

For a 29K feature dataset with 21K changes in the working copy, sno status went from ~7s to ~3m20s.

Key driver is this query (~200ms):

SELECT gpkg_sno_track.pk AS ".__track_pk", nz_mainland_powerline_centrelines_topo_150k.t50_fid, nz_mainland_powerline_centrelines_topo_150k."GEOMETRY", nz_mainland_powerline_centrelines_topo_150k.support_ty
FROM gpkg_sno_track
  LEFT OUTER JOIN nz_mainland_powerline_centrelines_topo_150k ON gpkg_sno_track.pk = nz_mainland_powerline_centrelines_topo_150k.t50_fid
WHERE gpkg_sno_track.table_name = 'nz_mainland_powerline_centrelines_topo_150k';

Becoming ~200s:

SELECT gpkg_sno_track.pk AS ".__track_pk", nz_mainland_powerline_centrelines_topo_150k.t50_fid, nz_mainland_powerline_centrelines_topo_150k."GEOMETRY", nz_mainland_powerline_centrelines_topo_150k.support_ty
FROM gpkg_sno_track
  LEFT OUTER JOIN nz_mainland_powerline_centrelines_topo_150k ON gpkg_sno_track.pk = CAST(nz_mainland_powerline_centrelines_topo_150k.t50_fid AS TEXT)
WHERE gpkg_sno_track.table_name = 'nz_mainland_powerline_centrelines_topo_150k';

I think the speedup is only possible via this method because Sqlite is basically untyped. Expectedly, removing the cast altogether fails tests on MSSQL & PostGIS, but I suspect they're impacted too. Need a better solution really so we can at least always make use of the dataset PK index. Minimum might be casting the other way (ie. tracking table → dataset pk type) with the logic there's often likely to be less changes in the tracking table than there are rows in the dataset table?

While I was profiling, disabled an extra hash verification per-object lookup.

Related links:

Checklist:

• Have you reviewed your own change?
• Have you included test(s)? covered by existing tests
• Have you updated the changelog?