Investigate using SpeedyAF for edit page rendering

[masaball]

Description

Currently the edit pages are populated from fedora. We could potentially decrease rendering times if we can leverage SpeedyAF. We will still need to load the fedora object for the actual update and save, but using SpeedyAF for the initial loading and populating of the edit pages could reduce the initial overhead and speed up load times.

As part of this, can/should we rework loading and authorizing the objects? Currently we use a load_and_authorize_resource callback, but this can be somewhat lengthy and may be triggering for each type of resource (fedora object, SpeedyAF proxy, raw solr object, etc) rather than running once.

Done Looks Like

• Use SpeedyAF for populating edit page fields instead of Fedora
• Change object authorization strategy from the current callback to something more performant

[masaball]

This work was put on hold during the final push to get 8.0 code complete. Current status is that the pages are successfully rendering from SpeedyAF without any reification but the "Save and Continue" functionality is not working. I think the object is being saved, but the user does not get redirected to the next step. Also, it is too aggressive with trying to use SpeedyAF because it errors when trying to create a new object since nothing is in Solr for the proxy to pull at that point.

Next steps would likely be for @cjcolvar and myself to pair up to work through the two mentioned issues and see if anything else comes up. Once the create and continue functionalities are fixed, I think it should be in a place for testing and benchmarking.