Libkey integration - requested changes

[Chloe070196]

Changes requested after code review, most of them performance-related, namely:

---

• check if a url contains a DOI

• check for libKey setting
  Only ever use the LibKey integration if a LibKey
  setting is associated with the active library.
  This aims to ensure that the LibKey integration
  code only runs if LibKey has been set up for the
  relevant library.

• do not proceed if no setting found

  Removes an unecessary fetch() call as find(true)
  already executes a fetch(), and changes the
  control flow so that getLibKeyLink() returns
  null early if no setting is found (only move on
  to creating an instance of CurlWrapper if the
  setting was found).

• remove duplicated lines

  These were likely involuntarily duplicated during
  a merge conflict resolution. Remove the redundant
  lines.

• remove unecessary module

  It was established that there is no need for the
  LibKey integration to be a module. This removes
  the SQL that would have added it to the modules
  table in the Aspen database.

---

To test:

• check functionality for eContent with DOI urls (test plans at 3956f87 and 4a1d87a )
• check functionality for eContent with urls that do not contain DOIs - must be preserved after applying the patch

[Chloe070196]

Two additional changes may still be required - awaiting feedback on whether they will need to be implemented or not

[AlexanderBlanchardAC]

Retested after changes made. The issues found during testing, error message for items with no doi and missing libkey link in the links section have both been resolved and all appears to be working as expected. The next commit addresses the url returned when it is not libkey (to ensure it defaults to the 856 u instead of returning an empty string).