Index update, Phase 2: Use new large_user_postcode index

[KludgeKML]

The updates added in PR #556 included a naive method of identifying relevant ONSPD records to update (fetching a list which had to be filtered by a select statement), resulting in a notable bump in CPU usage by the worker threads. This PR moves the "size" element from the free-form JSON results field into a specific field which can be indexed and searched in a single search.

Speed of the query code as reported by benchmark:

Before:
0.473827 s / call

After
0.000685 s / call

(Speed improvement of 690x on this code, which is called once a second)

Obviously there's a cost in writing, because the index has to be updated, so it's not plain sailing, but the benefits should outweigh the cost, we can monitor that on CPU usage.

Integration worker CPU and memory load over the last two weeks - low before PR 556, high after it, then low again after this PR is temporarily deployed - CPU and memory load seem to be marginally better even than before PR 556

Actual index and migration task added in #610

https://trello.com/c/Pf89f3wr/350-improve-worker-cpu-usage-on-locations-api, Jira issue PNP-6398

⚠️ This repo is Continuously Deployed: make sure you follow the guidance ⚠️

⚠️ Coverage note: test suite is set to fail if coverage drops below 100%. If you need to merge in an emergency, you will have to temporarily change branch protection rules. ⚠️

Follow these steps if you are doing a Rails upgrade.

[sihugh]

Looks like a nice change. I had a couple of questions:

• is the migration quick enough to make it through a standard deploy? (We've had some recent ones where it's hit a timeout and had to be decoupled into schema updates and rake tasks, or some such arrangement)
• can we drop any of the other indices after this one has gone in if we're worried about write performance?

[KludgeKML]

Looks like a nice change. I had a couple of questions:

• is the migration quick enough to make it through a standard deploy? (We've had some recent ones where it's hit a timeout and had to be decoupled into schema updates and rake tasks, or some such arrangement)

Good question - I think so, because I have deployed this to integration. Let me do that again, see how long the migration takes.

• can we drop any of the other indices after this one has gone in if we're worried about write performance?

I think we're not worried per se about write performance, I just mention it for completeness. Writing is relatively stable (we have a fixed rate of 3 writes per second, except during ONSPD imports), and it's all done in workers so doesn't affect the end user. But we can certainly audit the indices somehow to confirm whether there are any vestigial ones.