Reconsider linkeddata dependency

[jrochkind]

the linkeddata gem has given us periodic dependency tree challenges. Eg https://github.com/samvera/questioning_authority/pull/374#issuecomment-1239853716. Could/should the way we are using it be changed?

1. linkeddata gem is expressed as a development-only dependency, not a full runtime dependency. https://github.com/samvera/questioning_authority/blob/568382478a31cbb901aa58c7087d25e9023017bf/qa.gemspec#L33

   • Normally this would mean the gem is not used by actual production code, but is only used in, say, CI. But I don't think this is actually true of linkeddata.
   • Is it done this way intending it to be a kind of "optional dependency"? That a local app will have to add themselves iff they are using certain features? If so this should be documented and specified, and consideration given for:
     • Additional code to require the "optional" dependency explicitly such that you get a better error message if trying to use the features that require it, including version requirements. eg https://bibwild.wordpress.com/2015/09/09/optional-gem-dependencies/
     • OR extract the adapters that do use linkeddata into their own separate gem, with an explicit linkeddata (or other, see below) dependency?

2. linkeddata is mean to be an aggregate gem. Can we instead require/depend on just hte parts we actually use?

   • linkeddata maintainer writes:

     The linkeddata gem is specifically intended to be a meta-release that requires all the various gems in the eco-system. This undoubtedly includes many not necessary for every application. Consider requiring the specific gems you need directly, which will also significantly reduce your image size, if that's important.

   • I would say it's not just an issue of image size, it's an issue of reducing transitive dependencies to reduce possible dependency conflicts (as happened above with a confict involving yaml-ld, a dependency of linkeddata whose functions we aren't even using).
   • This would reuqire figuring out what individual specific gems we are actually using here, and how. This may be knowledge currently not in our institutional knowledge.

[jrochkind]

OK, we may actually switch the development dependency from linkeddata to specific sub-dependencies, in order to resolve a problem we had with bundler failing to be able to resolve a consistent dependency tree, see #374, and specifically https://github.com/samvera/questioning_authority/pull/374/commits/5dcf7f56522574e32d0fd18bacce89f180d4885a for which specific sub-dependencies I identified as necessary for tests to pass.

The outstanding issue still is... what are downstream apps supposed to be doing, are they supposed to be adding linkeddata or sub-dependencies to their own Gemfile as "optional" dependencies for certain features or adapters, and if so which ones?