Return remaining V2 fields

[jazairi]

Why these changes are being introduced:

The data model includes fields that are not yet returned in V2
of the API.

Relevant ticket(s):

https://mitlibraries.atlassian.net/browse/RDI-89

How this addresses that need:

This returns the additional V2 fields.

Side effects of this change:

• These fields have been added to the base set of fields, but this
  may require modification once we determine the extended set.
• The following fields included in this commit are not required for
  RDI: contents, call_numbers, holdings, literary_form,
  numbering, physical_description, `publication_frequency.
• Cassettes have been regenerated.
• The id field has been changed to timdex_record_id, as they
  seem to be the same (timdex_record_id is listed as a new field
  in V2 of the data model). I'd like the reviewer to confirm whether
  this is an acceptable approach, or if id should remain as mapped
  from timdex_record_id wih timdex_record_id returned as a separate
  field or not returned at all.

How can a reviewer manually see the effects of these changes?

Some of the new fields will be physical by calling the search endpoint o the V2 API (however, not all of them are represented in our test data yet).

Requires Database Migrations?

NO

Includes new or updated dependencies?

NO

[jazairi]

This branch has been deployed to TIMDEX staging.

[matt-bernhardt]

I've gone through the commit, confirmed that the tests still pass, and compared the current state of _base.json.builder to the v2 spec spreadsheet. I can confirm that every field in the spec is now listed in the base partial (and the base partial introduces no field not listed in the spec).

I'm not sure about the timdex_record_id question, though. I understand that breaking changes like renaming this field are permissible, but I'm not sure whether user expectations for an id field are strong enough to justify including this value twice (first as id and then again as timdex_record_id). It is hard for me to anticipate another possible returned ID that could result in another id - like a foo_id field and also a timdex_record_id, both of which would then be duplicated as just id.

I'm going to try and sleep on this, and come at the question tomorrow morning with a fresh mind. I'm posting this comment now to remind future-me of where I left off.

Questions in my mind right now include:

• Should _base.json.builder` alphabetize earlier fields? I see the new fields have been added in alpha order, but the earlier batch were not.
• I'm not sure I follow the rationale behind the changes in the cassettes, but this is more likely my end-of-day brain being generally confused.