Increase default file descriptor limit for couchbase-server service

Original Description

The default file descriptor limit is set to 70000 in /usr/lib/systemd/system/couchbase-server.service. We need to increase the limit to a higher value according to the operating system environment. On CentOS7, 1M is the maximum limit.

Extended

Currently we do a "ulimit -n 70000" or set the LimitNOFILE in systemd config on installation of couchbase-server service. Memcached default configuration has 60,000 connections but ns_server sets their own default in memcached.json to 65,000. Memcached uses 1 file descriptor per connection. Without changing any connection settings this leaves kv_engine with 70,000 - 65,000 - some overhead of the order of 1000-2000 file descriptors. Sarath mentioned in a slack conversation that magma was observed to be working well with 65K file descriptors but that they indeded on lowering the amount required. I'd propose for now that we bump the default file descriptor limit to 150,000 (double what we use and a bit extra). This would be plenty for magma on top of our current max connections limits in memcached whilst also giving us some overhead.

I found that on ubuntu 16.04 with kernel version 4.4.0-21 that I could set ulimit to a max of 2^20 (1,048,576). Same on debian8 with kernel version 3.16.0-4. I imagine the limit is the same for Centos7 that Sarath observed. 150,000 seems reasonable given limits on modern linux kernels/OSs.

I observed from all the vagrants I spun up looking at limits that /proc/sys/fs/file-max is generally defaulting to a value in the region of 100,000. This is max number of files open across all processes. The lowest I saw was in the region of 97,000 so that may be a better candidate, but I didn't look at every single OS/kernel version that we support. If we want a limit above this then we may need to add to our docs to suggest to customers that they also bump this value (or possibly do so ourselves at installation). Dave Rigby reminded me that  /proc/sys/fs/file-max is calculated by the OS based on amount of memory available so the limit in the vagrant isn't a good indicator of anything. For any production sized machine whatever the kernel sets should be fine. Annecdotally on our server in manchester with 128GB ram the file-max value is 13,175,866.