Add spark k8s operator launcher

[oavdeev]

What this PR does / why we need it:
This allows Feast to run Spark jobs using spark-k8s-operator.

To enable it:

1. set spark_launcher="k8s"
2. set spark_k8s_use_incluster_config to True or False, depending on whether spark is running in the same k8s cluster or not. Make sure that feast serviceaccount has permissions to create SparkApplication resources. Provide KUBECONFIG if running Feast outside of the cluster.
3. Typically you need spark_staging_location and historical_feature_output_location to be set and use s3a:// URL scheme if using S3.
4. Lastly, set spark_k8s_job_template_path to point to YAML template containing spark application configuration. Feast comes with one out of the box, but in production you'll likely want to provide a custom one.

Additional changes:

• Storage client now supports s3a:// URL scheme (used by OSS Spark to access S3, we didn't need this for EMR since it understands s3:// scheme just fine)
• For historical pyspark jobs, arguments are now base64+JSON encoded. Previously they were just JSON encoded, but with OSS spark that caused issues with proper quoting (I think the issue is somewhere in the docker entrypoint script provided with Spark, not the k8s operator itself).

Does this PR introduce a user-facing change?:

Feast now supports launching Spark jobs using k8s operator.

[oavdeev]

/kind feature

[oavdeev]

/retest

[woop]

I'm not sure if you saw #1198. Should we close that PR after yours has been merged, or first merge that one?

[oavdeev]

No i haven't. It looks like it is solving a slightly different problem, namely user-specified extra options. Don't feel strongly which one to merge first (and which one to rebase).

[woop]

@oavdeev looks good overall 👍

The only things that stand out are docs (tracked elsewhere in #1231) and tests. I'd feel a bit more comfortable having the tests as part of this PR, or did you have another plan (minikube/kind based)?

[oavdeev]

I'd feel a bit more comfortable having the tests as part of this PR, or did you have another plan (minikube/kind based)?

I'd rather add tests in a followup PR. I plan to add another integration test, alongside with test-end-to-end-[aws,gcp], and setting this stuff up tends to make a PR nearly unreadable due to lots of tweaks/rebases and retests.

[feast-ci-bot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: oavdeev, woop

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

• OWNERS [woop]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[woop]

/lgtm