feat: Add gRPC Registry Server

[tokoko]

What this PR does / why we need it:
Implements a read-only python grpc server that wraps calls to the registry configured in feature store. Adds a cli command to start registry server from feast cli. Primary motivation behind this feature is to enable non-python feast applications (java feature server) to easily communicate with feast registry.

Which issue(s) this PR fixes:
Fixes #3901

[sudohainguyen]

do you mind adding a quick guide how to define registry in feature_store.yaml within the PR description? so that we can update documentation accordingly in another PR

[tokoko]

Thanks for asking that. I'm trying to split the changes into smaller PRs, so the short answer right now is that you can't. This PR enables users to call feast serve_registry with a normal feature store configuration that will start the registry server on a specified port. I'm thinking of adding two different clients in subsequent PRs, a python client that will extend BaseRegistry and a java client for java feature server.

I'm not sure yet how feature_store.yaml should look like, I'm interested what others think about that. I think the cleanest approach would be to let the users use feature_store.yaml as a way to configure their clients. So, in cases when they need to access the registry directly (including the container from where feast serve_registry will be run), the config file will look something like this:

project: <your project name>
...
registry:
    registry_type: sql
    path: postgresql://postgres:[email protected]:55001/feast
    cache_ttl_seconds: 60

For applications where clients (java or python) connect to registry server, it might look something like this (this is still unimplemented!!!):

project: <your project name>
...
registry:
    registry_type: server
    url: grpc://127.0.0.1:8888

The biggest downside obviously is that you will need to have two different configurations depending on how you want to configure your client, but imho that's more of a feature than a bug. For example if a feast admin wants to force users to exclusively use registry server rather than connect to underlying implementation, they would be able to only share server information and hide implementation details. The same approach could in future be extrapolated to online store configuration, if you would like your store.get_online_features call to query feature server rather than an underlying online store, you would configure your store something like this:

project: <your project name>
...
online_store:
  type: server
  url: http://127.0.0.1:80 // or grpc://127.0.0.1:80

I definitely want to know what you guys think before delving into the implementations too much.

[sudohainguyen]

@tokoko got your ideas, and I believe this is a pretty great one, which reduces headaches connecting components

[sudohainguyen]

lgtm

[HaoXuAI]

Realy great work. Nothing to comment on.