Config Server tutorial for Gateway as a Service use case

First comment:

here is a chat transcript that captures the essence of this tutorial

```
Alice: basically you launch sync gateway with a config file based on this example https://github.com/couchbase/sync_gateway/blob/master/examples/config-server.json and then you can hit http://localhost:4985/_admin/
Alice: except for the builtin db at http://localhost:4984/db/ requests like http://localhost:4984/foobar/ will try to contact the config server to lazy load config
Bob: thats fucking nice
Alice: note the 4984 vs 4985 admin port
Bob: i’m assuming you have some built-in sharing strategies ?
Bob: err
Bob: sharding*
Alice: we let couchbase server do that
Bob: whats the main purpose of have the configuration server?
Alice: for you i’d suggest the “local” storage on ebs where you could have hundreds of users, and when a user has performance demands move them to a Couchbase Server bucket
Alice: lazy load config so you don’t have to parse 10 million database entries on SIGHUP
Alice: hundreds of active users
Alice: the nice thing about this is you can nginx hash a sync gateway resource pool (basically hash database name to ebs disk) and it should be self healing as you restart gateways. For databases that need more than one sync gateway node, you’d move them to Couchbase Server.
```

see other comments: https://github.com/couchbaselabs/couchbase-mobile-portal/issues/262