Refactor how TIMDEX records are nomalized

[jazairi]

Why these changes are being introduced:

Prior to USE, TIMDEX records were largely normalized in the view layer. While not ideal, this made some sense given that TIMDEX was the sole source we were working with in the UI.

Now that we have introduced Primo results in USE, we should normalize TIMDEX records similarly, such that the two share a similar data structure.

Relevant ticket(s):

• USE-73

How this addresses that need:

This introduces NormalizeTimdexReuslts and NormalizeTimdexRecord models to parallel the Primo models. The normalization models share a structure to the extent that it is meaningful. Source-specific fields that will be used in the application are indicated as such.

Side effects of this change:

• Modifications to various parts of the view layer were necessary to
  retrofit this change.
• In some cases, we are only mapping the necessary data. (E.g., TIMDEX
  links array only includes source link.) This is subject to change as
  we learn more about UX requirements.
• The Primo result partial has been minimized to more closely resemble
  the TIMDEX partial. This is also subject to change based on UX
  requirements.

Developer

Accessibility

• ANDI or WAVE has been run in accordance to our guide.
• This PR contains no changes to the view layer.
• New issues flagged by ANDI or WAVE have been resolved.
• New issues flagged by ANDI or WAVE have been ticketed (link in the Pull Request details above).
• No new accessibility issues have been flagged.

New ENV

• All new ENV is documented in README.
• All new ENV has been added to Heroku Pipeline, Staging and Prod.
• ENV has not changed.

Approval beyond code review

• UXWS/stakeholder approval has been confirmed.
• UXWS/stakeholder review will be completed retroactively.
• UXWS/stakeholder review is not needed.

Additional context needed to review

I'd like the reviewer's opinion on minimizing the Primo result partial and/or selectively normalizing data (see the note about the links method in the commit message). It's a bit of a chicken-and-egg situation, since I assume we may want more data in the results at some point, but it's not clear yet what.

Code Reviewer

Code

• I have confirmed that the code works as intended.
• Any CodeClimate issues have been fixed or confirmed as
  added technical debt.

Documentation

• The commit message is clear and follows our guidelines
  (not just this pull request message).
• The documentation has been updated or is unnecessary.
• New dependencies are appropriate or there were no changes.

Testing

• There are appropriate tests covering any new functionality.
• No additional test coverage is required.

[coveralls]

Pull Request Test Coverage Report for Build 18603748433

Details

• 77 of 77 (100.0%) changed or added relevant lines in 4 files are covered.
• No unchanged relevant lines lost coverage.
• Overall coverage increased (+0.1%) to 98.287%

---

Totals
Change from base Build 18602295760:	0.1%
Covered Lines:	918
Relevant Lines:	934

---

💛 - Coveralls

[JPrevost]

There's a bug in the GDT view that prevents full record views from working and I have a suggestion to change a method name to match the normalized keys. I also think maybe there is a partial that should be deleted but I didn't dig too deeply to see if I'm correct.

I believe the rest is comments/questions/info for later.

[jazairi]

@JPrevost Thanks for the feedback! I think the latest commit addresses everything that should be fixed at this point. As for the others:

• added a note to USE-95 to fix pagination for TIMDEX
• opened USE-109 to refactor the hash keys as symbols
• opened USE-110 to make active tab state more consistent