Port Python client from main repository

[hectcastro]

Split the Raster Foundry Python client out from the main repository and do any work necessary to support cutting a release:

• Rename to rasterfoundry
• Add more layers of release testing to tox
• Add Travis CI support
• Add license
• Update README

Fixes raster-foundry/raster-foundry#1598.

---

Testing

Inspect the diff and ensure the Travis build succeeds.

[notthatbreezy]

Looks good -- the only thing I'm hesitant about is how we're going to manage keeping this spec.yml in sync with the spec in the main repository. That's more of a process problem than code though so I think it's something we'll just have to be aware of.

[hectcastro]

Yeah. At a high level, I figured that we'd encode the process of getting the latest spec in update (not added yet).

Some questions that come out of that for me:

• Do we always just pull the latest spec and expect development to happen based on that?
• Do we do something in the spec publishing process to version it so that the client is always associated with a particular version (I noticed in version in the spec itself)?

Following the Docker SDKs as an example, the API has a version (we can use the version inside of the spec file). The SDKs are setup to interact with a specific version of the API. Updating the API version reference in the SDK lead to major version bumps of the SDK.

[notthatbreezy]

Versioning the api client to match the version that is deployed makes sense to me -- and seems to be the convention in Docker right (e.g. python:3.6 is a container with version 3.6.x of python even though this could technically be a different iteration of the client)? If that's what you mean.

I don't think we have been paying attention to the version in the spec itself, but that should probably match the version that is deployed -- even if we don't yet have a versioned API per se.

I can also see the case where there are going to be additions to the API client that should not/would not necessitate deploying new versions of the API. There is quite a bit of catch-up to gain parity with the API I think that we will not want to deploy a new version of the application just to keep in sync.

So maybe in the short term we version the python client separately from our API, but ensure that the releases do not go beyond the application release numbering so we can sync them at a later time.