catalogsource: allow configuring gRPC server to use well-known opm

As the file-based catalog schemas mature, the couping between `opm` and
the catalog data is effectively removed. We can take advantage of this
new property in the system to not require that a server binary exist in
the catalog index image, and remove many of the pain-points that come
from using the embedded server binary.

Signed-off-by: Steve Kuznetsov <[email protected]>

crds/operators.coreos.com_catalogsources.yaml

@@ -532,6 +532,16 @@ spec:
                                   topologyKey:
                                     description: This pod should be co-located (affinity) or not co-located (anti-affinity) with the pods matching the labelSelector in the specified namespaces, where co-located is defined as running on a node whose value of the label with key topologyKey matches that of any node on which any of the selected pods is running. Empty topologyKey is not allowed.
                                     type: string
+                    extractContent:
+                      description: ExtractContent configures the gRPC catalog Pod to extract catalog metadata from the provided index image and use a well-known version of the `opm` server to expose it. The catalog index image that this CatalogSource is configured to use *must* be using the file-based catalogs in order to utilize this feature.
+                      type: object
+                      properties:
+                        cacheDir:
+                          description: CacheDir is the directory storing the pre-calculated API cache.
+                          type: string
+                        configDir:
+                          description: ConfigDir is the directory storing the file-based catalog contents.
+                          type: string
                     memoryTarget:
                       description: "MemoryTarget configures the $GOMEMLIMIT value for the gRPC catalog Pod. This is a soft memory limit for the server, which the runtime will attempt to meet but makes no guarantees that it will do so. If this value is set, the Pod will have the following modifications made to the container running the server: - the $GOMEMLIMIT environment variable will be set to this value in bytes - the memory request will be set to this value \n This field should be set if it's desired to reduce the footprint of a catalog server as much as possible, or if a catalog being served is very large and needs more than the default allocation. If your index image has a file- system cache, determine a good approximation for this value by doubling the size of the package cache at /tmp/cache/cache/packages.json in the index image. \n This field is best-effort; if unset, no default will be used and no Pod memory limit or $GOMEMLIMIT value will be set."
                       pattern: ^(\+|-)?(([0-9]+(\.[0-9]*)?)|(\.[0-9]+))(([KMGTPE]i)|[numkMGTPE]|([eE](\+|-)?(([0-9]+(\.[0-9]*)?)|(\.[0-9]+))))?$