✨ Get Next & Previous candidates buttons to work with full list of candidates

[gobyrne]

✨ Feature

In #10271, we are adding functionality to use the "next" and "previous" candidates buttons (on the candidate application page) with all candidate tables. However, it will be limited to only the candidates on the current page (from paginated query). This issue is to make it work with the full list of candidates instead.

🕵️ Details

The list of candidates being paged through should depend on the filters applied to the original table but should not be restricted to the current page or page size of the table.

🎨 Design File

Include a link to the design file (if it exists).

🧑‍🎨 Designer

Include the author of the linked design file's name (or even better, their @githubUsername) for future reference.

📸 Screenshot

Add a screenshot of the new feature (if possible).

🙋‍♀️ Proposed Implementation

We believe this will be easier after we've implemented cursor-based pagination. Then, instead of storing a list of candidate ids in the page state, we'd store the filters associated with the query (or the query itself?) along with the current cursor.

(Would cursor based pagination allow for retrieving the previous result? We might want to store the previous cursor as well.)

🌎 Localization

(optional) Provide any new copy along with translations available.

✅ Acceptance Criteria

A set of assumptions which, when tested, verify that the feature was properly implemented.

• [ ] The list of candidates being paged through by next/previous buttons reflects the list of candidates who would appear in the original table (ie the same filters apply)
• [ ] The list of candidates being paged through by next/previous are not restricted to the candidates which appeared on the "current page" of the table.

🛑 Blockers

Issues which must be completed before this one.

### Blocked By
- [ ] #10271
- [ ] https://github.com/GCTC-NTGC/gc-digital-talent/issues/10827

[gobyrne]

@tristan-orourke were you gonna add a proposed implementation to this? Or was it @esizer ?

[github-actions[bot]]

Status: Error :warning:

Issues blocking this PR:

• 10271 :heavy_check_mark:

• NaN :warning: Issue/PR not found

  ---

  This comment was automatically written by the Blocking Issues bot, and this PR will be monitored for further progress.

[esizer]

This is currently blocked on cursor pagination and there is no absolute way forward right now on that. If this is an important feature there may be a hack-y solution 🤔

I am thinking that if we get some values from the main table, we can pass those on to the next page in the router state to make a fairly educated guess on the "next" candidate. If we know the following we should be able to get it:

1. The index of the link clicked
2. Current page size
3. Total items
4. Filters applied

If we know the index and page size, we could determine the offset and pass a page size of 3 using the first and last item in the list as the prev/next links 🤔

let offset = index * currentPage - 1; # minus one so the first item is actually the previous item
if(offset < 0) { 
  offset = 0;
}

const [{ data }] = useQuery({ 
  query: CandidateNavigation_Query,
  variables: {
     page: offset,
     first: 3,
     ....filters
  }
});

const candidates = unpackMaybes(data?.poolCandidatesPaginated?.data);
let next, prev;
const currentIdx = candidates.findIndex((candidate) => candidate.id === candidateId);

if(currentIdx > 0) {
    prev = candidates[currentIdx - 1];
}

if(currentIdx + 1 <= candidates.length - 1) {
  next = candidates[currentIdx + 1];
}