Adding one to vespa passage match pages.

[THOR300]

Description

Updating the pydantic object for a search response that is utilised by the vespa conditional flow for a search response.
The update is to add a root validator method that increments the passage match page number by one.

Type of change

• Bug fix
• New feature
• Breaking change

How Has This Been Tested?

Added some explicit tests to assert that the response objects correctly convert the index of the page to the required page number. This should help us should we upgrade pydantic etc.
The plan is once merged to deploy to staging and verify via the api.

Reviewer Checklist

• The PR represents a single feature (small driveby fixes are also ok)
• The PR includes tests that are sufficient for the level of risk
• The code is sufficiently commented, particularly in hard-to-understand areas
• Any required documentation updates have been made
• Any TODOs added are captured in future tickets
• No FIXMEs remain

[linear]

PDCT-549 Update Vespa passage match page numbers indexing to match OpenSearch

Please see screenshot for a visual view of the issue.

In OpenSearch the pages are index from 1 (I think), whereas in Vespa it appears we are using a 0 indexing. So page 23 in OpenSearch is page 22 in Vespa. This is obviously having an affect when we are displaying the passage highlights within the app.

Rather than me writing lots of business logic to determine which search provider we are using and adjusting the page number accordingly, could we update the vespa results to match that provided by OpenSearch on page numbers? I'm happy to revisit this later when we remove OpenSearch.

[olaughter]

Good work! Great adding a test too 🙌