Store resources being administered by the aggregated apiservice in a custom storage

[anik120]

Motivation:

As a follow up to #39, configure the aggregated apiservice to store the objects in a custom storage, so that the main etcd storage is not misused for storing the resources created by the catalog controller.

Some potential options:

• A custom etcd storage, eg
• A custom bbolt storage

[anik120]

cc: @joelanford I know you had some opinions about which storage is better suited for our use case, considering atomic availability of content from a catalog during creation/re-sync etc.

[anik120]

Also, initial thought is that it'll be cleaner to have this storage running in a separate pod, that the aggregated apiservice connects to using api endpoints, so that the apiservice process isn't also responsible for running the db in memory. That way, if the process running the db is unavailable for any reason (eg exceeded memory limits and therefore is getting kicked out by the main apiservice), the running aggregated apiservice is still available to communicate to clients that the storage is unavailable. This also off loads risks related to aggregated apiservice unavailability (I.e potential domino effects to the main apiservice)

[everettraven]

Closing this as a different route has been decided for storing and serving catalog contents. See #113 , #114, and #139 for more information