Add data and actions to New Tab page

[nina-py]

Goal

Get the New Tab page working as intended.

Implementation Decisions

• Added two tabs to the New Tab page: Live and Scheduled, both with pagination.

• Added Live/Scheduled/Removed labels.

• Wired up the "Edit" and "Remove" buttons to the right actions.

• Added (some) tests.

• Updated GraphQL schema for the local API with new flags (isLive, isRemoved, etc.) and the removalReason field.

• Updated mock data generation script so that it now reliably generates three unique feeds: en-US, en-GB and de-DE.

• Removed the last of console warnings by adding types to values returned by mutation hooks.

Note that the frontend hides the "Remove" button for removed prospects - only the "Edit" button remains available - my thinking was that you can't remove it twice - that would only overwrite the value in the removalReason field.

Also, it is unclear where the contents of the removalReason should be displayed - perhaps in the history field of the Edit/Edit & Approve form? Added this to the list of UI tweaks under consideration.

Outstanding tasks:

• [ ] Write more tests - see comments below.
• [ ] Add form to capture removal reason and confirm prospect removal - to be addressed in another PR as this one is already quite large.

[nina-py]

The work in this PR, particularly the tests required, exposed an interesting conundrum with the tests. Apollo Client expects the mocks for each query to match the objects fetched by those queries. The result returned by the query itself is an object of the following shape:

{
  data { 
    allProspects: Prospect[]
    totals: id[]
  }
}

It doesn't care much for the extra layer I added to the local API so that the output conforms to the spec:

  data {
    data: Prospect[]
    meta: {
      ...metaProps
    }
}

Indeed, it appears that it's impossible to test the Prospects and New Tab pages using just the local API, so I have removed all but one (tab-related) test for those two components. For the time being, the code that fetches queries from the GraphQL server and passes it to various components remains without test coverage (mutations are covered though).

One possible way to improve this would be to increase test coverage by testing the code against a copy of the private API and, at the same time, being able to request those meta fields so that they are part of the GraphQL query and can be used in the mocks. Apparently it's possible to use encrypted secrets in GitHub actions.