API for Remote Function Rest Client

[majetideepak]

We are adding a Rest Client for Remote Functions here #10911
I want to propose an API for Velox so that various use-cases, including AI/ML can benefit from a standard API.

At a high level, Remote Function Service with Rest would involve all the components needed to read and write data from a remote endpoint, say S3. These broadly include

1. Authentication + Authorization
2. Network Security
3. Error Handling due to network errors.

Velox should only provide a minimal API similar to the FileSystem API, which includes extensibility.

1. RemoteFunctionClient Factory + registration
2. ClientConfig
3. RemoteFunctionClient APIs: listFunctions(), getFunctionSignature(name), invokeFunction(name), processResult(), refreshClient(), retry(), handleError(), maskResult().

The current model is to create one client per RemoteFunction.

[majetideepak]

CC: @pedroerp, @aditi-pandit, @Joe-Abraham

[pedroerp]

@majetideepak this makes sense to me. In our internal usage of remote functions, thrift handles network security and retries. Adding APIs to list functions and signatures would also be useful so that the client (Velox) could automatically discover and register remote functions, if needed.

Cc: @amitkdutta @sebastianopeluso who are also interested in remote function execution for Prestissimo

[aditi-pandit]

We had a long discussion about this internally at IBM and putting some more context here for others @pedroerp

@tdcmeehan Tim had a proposal for a Rest based function server for Presto/Prestissimo last year prestodb/rfcs#25 and we have been executing on it.

@amitkdutta @sebastianopeluso : Would be great to get more feedback from you folks on that doc to decide the further action plan.

One component of that design was to add a Velox runtime for a RestFunction abstraction and we were building of the lines of the RemoteFunction with thrift work that Pedro had done. That was the genesis of the PR being discussed.

@majetideepak had a valid point about handling security or other special configuration and behavior for the RestClient in an API that is implemented by the application service. There was also general agreement that Prestissimo already has an HttpClient with many of the security functionality that is expected for the implemenatation https://github.com/prestodb/presto/blob/master/presto-native-execution/presto_cpp/main/http/HttpClient.h which we can use.

At IBM we have a very high priority use-case to expose legacy Presto Java UDFs via the Rest based function server. We cannot rewrite these functions in C++ because they are written by our client's client. For that use-case we have some open-ended questions from a platform perspective viz if will do an over the network service or setup a function server local to each worker node itself to improve performance. Or if there are other ideas around connection pooling etc that work out for us. We want to figure all this before making a reasonable proposal to Velox as it would be expected to be re-used across services. We will discuss with the Gluten team as well about it.

To make progress on the PR front, we will continue with implementing the current PR on the Prestissimo side with its HttpClient, and come back to Velox after we have some solid, proven code.