When user inits Ray with a working_dir, under the hood we package the user-local directory/zip and upload to the Ray cluster. However we are uploading it to the GCS Internal KV, which may pose unnecessary burden to our global process, who can already be very busy on large clusters.

This PR introduces a new "remote protocol"plasma. It spins up a global singleton detached actorDataHolder, which stores bytes into the Object Store. The package uploader invokes a Ray remote method to store it; the package downloader just do regular ray.get to download.

Problem: this requiresray be initialized in the first place. So when you doray.init(runtime_env={"working_dir":"./"} you introduce a circular dependency between ray and DataHolder, which fails. For similar reasons, Ray Client can hardly do this.

Fortunately, Jobs can do that just fine. When you doray job submit, it actually makes a HTTP PUT call to the dashboard JobAgent, which invokes anything needed to save the package. And there, DataHolder can work.

In this PR:

• a singleton DataHolder actor
• a new Protocol.PLASMA type
• changed all code from defaulting to GCS to require a Protocol type, and work with DataHolder if it's PLASMA.
• Use the new plasma in JobSubmissionClient & ServeSubmissionClient.

What's not changed:

• Ray driver script:ray.init() still uses GCS.
• Ray Client still uses GCS.

In the long run: we can extend Ray driver script & Ray client cases to all use HTTP PUT, and remove GCS code path.