Sophroid 1.0

Sophroid 1.0 Merge request. 

Sophroid components included in this merge request:

1. A gRPC server which serves envoy requests according to the xDS protocol 
2. Backend service 1: CDS: Cluster discovery service (served over the grpc server) 
3. Backend service 2: LDS: Listener discovery service (served over the grpc server) 
4. Processor (builds resource map from source config & generates snapshot for cache) 
5. Cache (snapshot generated based caching) 
6. Watcher (dynamic file watcher which enables real time snapshot generation and caching at each event in file)

 Tree-level mapping of components to files: 

• cmd/sophroid/main.go Sophroid entry point, instantiates the cache and xDS server and runs the xDS server process, while watching the file for any changes. 
• Internal/[..]/processor/processor.go Defines the file parser and processor which extracts resources from the config file, generates a Snapshot structure which describes the configuration that the xDS server serves to Envoy.
• Internal/[..]/server/server.go Runs the xDS control plane server.
• Internal/[..]/watcher/watcher.go Defines the process for watching for for file changes and notifies over channels either anytime an event or an error has occurred
• Internal/[..]/xdscache/cache.go Defines the xDS cache and the interface between the cache and resource maps used in the snapshot.  
• config/config.yaml The source information configuration deployed to Sophroid, used to extract the upstream resources envoy will proxy to  in addition to the port/ip envoy will listen on, and how to proxy the requests from clients to the clusters defined earlier.
• hack/sophroid-envoy.yaml The configuration deployed to envoy, which points to the control plane xDS cluster on port 18000.

Some changes to be aware of: 

In this milestone, Sophroid serves a static envoy configuration structurally equivalent to one generated in production mw-debug-envoy.yaml with the exception of a few changes highlighted below. Although these changes are recorded here for reference, it is likely that they will be addressed in the template in production and need not be addressed in Sophroid in the upcoming phases where the static file is replaced with a template. 

These changes include: 

1. The access_log field is restructured as an array of access_logs rather than a single AccessLog object in compliance with the admin message in the bootstrap proto definition.  
2. The cipher_suites fields in the transport socket field are restructured as an array of strings rather than a single string in compliance with the cipher_suites message in the transport socket proto definition.
3. The tls_certificate_sds_secret_configs is restructured as an array rather than a single object in compliance with the tls secret proto definition. 

Additionally some design decisions to be aware of: 

1. We convert yaml to json before unmarshalling to the proto definitions due to the protobuf message types defining json struct tags but not yaml struct tags. We do this by utilizing the kubernetes-sigs/yaml package to convert yaml to json as well as the protojson package to unmarshall the json to protobuf. 
2. Since our configuration utilizes some embedded proto types in the typed_config fields, such as "@type": type.googleapis.com/envoy.extensions.access_loggers.file.v3.FileAccessLog, we include these embedded types into our processor.go file under imports but plan to circumvent the need to add these embedded types manually in the coming phases. Further details in this regard to come.