Improvements to the Scheduler Client

[Cryptophobia]

From @helgi on September 15, 2016 22:0

This is an umbrella ticket and not all of these things need to be done urgently. Just didn't want to create bunch of tiny tickets just yet

• When fetching / creating resources can the data be stored internally on the object and run certain function without needing to pass in the structs (move response to attribute). This would amount to being able to do pod = scheduler.pod.get('blah'); pod['metadata']['name'] == 'foo'; pod.update() - note the lack of .json() and such, as response would not be returned anymore by default.
• Can we store pod/container objects but turn them into a dict for requests (create / update / etc)? makes it all flow nicer, could get rid of manifest()
• memoize results of version and more! This can be applied per function
• have the client understand throttling from Kubernetes - Does anything need to be done? Backoff?
• Start validating inputs? Or make API server catch all those and just bubble it up... our models should catch it anyway

Removing dependency on Django / DRF in Scheduler:

• remove django settings usage (testing only atm)
• remove reliance on django cache (testing only)

Copied from original issue: deis/controller#1072