Migrate SDKs to use Native types instead of Protobuf types #766

Background

One of the stumbling blocks working on PR #658 with the SDKs is that the Python and Golang SDKs directly expose the Serving API to users. This is a problem changes with the Serving protobuf API will propagate to user API changes on the Python and Java client. This makes API compatibility hard to track and maintain. (see @ches's comment about it here)

Problem

Currently the SDKs expose internal Protobuf types directly to users.
For example:

• Python SDK
  

  feast/sdk/python/feast/client.py

  Line 619 in a33883f

  ) -> GetOnlineFeaturesResponse:

• Golang SDK
  

  feast/sdk/go/client.go

  Line 84 in a33883f

  *serving.GetFeastServingInfoResponse, error) {

This poses a problem as:

• This makes the gRPC API exposed by Feast Serving/Core a user facing API, affecting downstream systems if changes are made to it.
• Users prefer to deal with native types instead of Protobuf types. For example, Python users prefer to interact with datetime.timedelta instead of Protobuf's Duration type.

Proposed Solution

1. Row API (similar to Java SDK’s Row) to be introduced to Python and Go SDKs as an higher level API.

• ie Row would be used to abstract away GetOnlineFeaturesResponse etc.

feature_rows = client.get_online_features(....)

2. Use native types in User Facing SDK APIs

• ie:

func (fc *GrpcClient) GetFeastServingInfo(....) map[string]string