Remove @lukemorales/query-key-factory, unblock react-query v5 upgrade

[ChristopherChudzicki]

What are the relevant tickets?

Prerequisite for #1940

Description (What does it do?)

This PR removes @lukemorales/query-key-factory, which we had been using to create query configurations for @tanstack/react-query. However:

• @tanstack/react-query was released about 1.5 years ago and has a number of improvements. A long open issi
• @lukemorales/query-key-factory does not support v5, and the open issue Support for TanStack Query v5 lukemorales/query-key-factory#73 to add support shows no progress. A PR to add support was closed. I am not optimistic support will be added any time soon.
  • query-key-factory more or less works OK with v5 despite official support. However, it does lead to some TS issues that are very hard to resolve.

How can this be tested?

The site should function exactly as before.

What I have checked is:

1. basic functionality of pages (home, search, dashboard, department/unit/topic listing, etc)
2. query invalidations:
   • Add / remove a resource to userlist. The bookmark should fill / unfill appropriately.
   • At /dashboard/my-lists/, create / delete / edit userlist. The listing page should update appropriately.

[ChristopherChudzicki]

The structure above (and in other queries files) is based on https://tkdodo.eu/blog/effective-react-query-keys#use-query-key-factories (blog by one of the maintainers).

Still a "key factory", but a little less automated than it was with @lukemorales/query-key-factory.

The main downside is that, in contrast to @lukemorales/query-key-factory, we are now responsible for ensuring the keys are unique.

[ChristopherChudzicki]

I haven't updated to v5 in this PR, but once we updated to v5 (which should be easy now that @lukemorales/query-key-factory is gone), all these satisfies QueryOptions should be replaced with https://tanstack.com/query/latest/docs/framework/react/reference/queryOptions

[jonkafton]

Looks good and is actually a cleaner API that we had previously (loses ._ctx and ._def).

I'd consider an alternative along the lines of below, though I appreciate it may be better to alway call a function for the keys regardless of whether it accepts params.

const ROOT_KEY: RootKey = "articles"

const articleKeys = {
  root: [ROOT_KEY],
  listRoot: [ROOT_KEY, "list"],
  list: (params: ArticleListRequest) => [ROOT_KEY, "list", params],
  detailRoot: [ROOT_KEY, "detail"],
  detail: (id: number) => [ROOT_KEY, "detail", id],
};

I'm not massively seeing the value of a key factory layer inside of the query hooks, which could directly create their keys and call the APIs. Convenient and a safer way for retrieving keys for clearing cache across files perhaps, though perhaps when we upgrade react-query we can find a pattern that better encapsulates this logic without exporting keys.

All works great.