Coding standards, database standards, and performance pass

[qadan]

Supersedes #12, #13, and #14, which I'm closing.

This pull encompasses a great deal of things, so a summary will probably be extremely helpful here:

• Coding standards passes:
  • phpcs passes for Generic, Drupal, and DrupalPractice
  • phpcpd passes
  • PHP lint passes
  • This included function and class variable documentation and comprises the bulk of changes
• The usage of \Drupal:: has been almost completely removed, except where absolutely necessary
  • Dependency injection has been implemented everywhere that it possibly can be
  • This probably represents the second largest chunk of changes
• Anything that was previously calling Markup::create() or render() has been replaced with full renderable arrays
  • In the cases where markup is complex, these renderable arrays now reference twig templates
  • Translatability has been ensured for all renderable strings in the module.
• Cache tags and contexts are implemented in renderable arrays, access controllers, and in the embargo entity type itself, so that caches no longer have to be globally flushed or have their max-age set to 0
• embargoes-file-embargoes.js and its corresponding library file has been removed so that jQuery isn't overriding properties set by the theme
• An EmbargoedAccessInterface has been implemented to allow entities of various kinds to determine how they wish to restrict access to entity types or provide redirection
  • Base implementations have been created for node, media, and file, that move out a lot of the logic from embargoes.module
  • This was done partially to remove duplicate code, and partially to ensure cacheability of results
• An access control handler for files, EmbargoesFileAccessHandler, has been implemented, and asserts itself by altering the file entity type
  • This overrides the default site behaviour (which allows files to be viewed/downloaded with no access control when stored on the public filesystem) by instead asking first if an embargo should prevent access.
• EmbargoesEmbargoesService::getParentNidsOfFileEntity() now checks references for files in image fields
  • This change allows embargoes to have an effect on files stored on media using an 'image' field.
• IP embargo redirection is now managed by an EventSubscriber hooking into the request event itself, as the previous method of manually generating a RedirectResponse and calling send() was causing problems with cached headers being present.
• Some database optimization has been done:
  • Columns are postgresql-friendly
  • Indices have been implemented
  • Text repetition has been reduced, specifically by representing an embargo's notification status as an 8-bit integer instead of a string
• A schema has been implemented for embargoes.settings
• The log controller has been removed and replaced with complete views integration for the embargoes_log table in a submodule, embargoes_log_views.
  • A default log view is included
  • Plugins for the special log data model pieces are included
  • A wizard plugin is included to create new views
  • The view wires up node and user relationships so that they're accessible when creating or modifying embargoes log views

The one thing that's not implemented here that I very much would have liked is to move the access control stuff to a plugin system. I'm not a huge fan of the fact that I've implemented access control as services, or hard-coded those services into specific hooks/the IP redirect subscriber. This was kind of a quick n' dirty solution; it would make far more sense to implement a plugin so that individual entity types could determine whether or not they should be accessible based on an embargo, then have the access hook and event subscriber vaccum them all up when Drupal builds its cache. That's an improvement for a later day, though.

One current unresolved issue of note is the fact that the EmbargoesNotificationsForm isn't wired up to anything - there's no embargoes.notifications schema, and it doesn't appear that embargoes.notifications is referenced anywhere else. This wasn't really considered an issue for this pass but is probably worth looking into a solution in the future.

[seth-shaw-unlv]

@qadan , I believe the reason why a string was used here was so that a username would persist even after the user is deleted from the Drupal instance.