Configure appropriate resource limits for k8s-brokered service plans

[jmcarp]

In order to ensure k8s-brokered services don't cost us ridiculous amounts to run, we want to specify reasonable limits and document them for customers.

Acceptance Criteria:

• [ ] We demonstrate that a churning service doesn't impact availability for others
• [ ] It's possible for customers to discover the resource limits associated with plans available to them

Implementation sketch:

Do research

Configure disk, memory, and cpu limits per service, possibly with multiple plans per service

• [ ] elasticsearch
• [ ] mongodb
• [ ] postgresql
• [ ] mysql
• [ ] redis

[datn]

Re: ES resource allocation, we definitely want the ES_HEAP to be no more than half the allocated memory, even in a container, because Lucene uses the rest of the memory (for eminently cacheable objects) that vastly improves performance (in semi-extreme cases, from unusable to barely usable):

https://www.elastic.co/guide/en/elasticsearch/guide/current/heap-sizing.html

https://www.elastic.co/blog/how-to-make-a-dockerfile-for-elasticsearch