Tune transfer buffer size
diff --git a/src/common/state/ray_config.h b/src/common/state/ray_config.h
index 2bd953c48c5f8..19507b8362d88 100644
--- a/src/common/state/ray_config.h
+++ b/src/common/state/ray_config.h
@@ -97,7 +97,7 @@ class RayConfig {
         local_scheduler_fetch_request_size_(10000),
         kill_worker_timeout_milliseconds_(100),
         manager_timeout_milliseconds_(1000),
-        buf_size_(4096),
+        buf_size_(80 * 1024),
         max_time_for_handler_milliseconds_(1000),
         size_limit_(100),
         num_elements_limit_(1000),

This PR is supposed to address one problem that we have seen while testing Ray's data plane, namely that data transfers are not using the full network bandwidth. This PR addresses the problem by resizing the transfer buffer size. The new value has been determined by running the following test on EC2: Two m5.4xlarge nodes were started, `iperf` gave the following measurement for the network speed between them:
```
[ ID] Interval       Transfer     Bandwidth
[  3]  0.0- 0.9 sec  1.00 GBytes  9.71 Gbits/sec
```

For different values of the `buf_size`, I put an object into the object store by using a driver on one node via 
```
In [4]: import numpy as np

In [5]: a = (255 * np.random.random(100 * 1000 * 1000)).astype(np.uint8)

In [6]: x = ray.put(a)

In [7]: x.id()
Out[7]: b'\x83\xfd:\x97\x1a\xa5\xff7t\xff(\n\xe0\x1e\xa6\xa5\xbe>\xd7\xe2'
```
and then getting it from  a driver on the second node, via
```
In [6]: x = ray.local_scheduler.ObjectID(b'\x83\xfd:\x97\x1a\xa5\xff7t\xff(\n\xe0\x1e\xa6\xa5\xbe>\xd7\xe2')

In [7]: %time ray.get(x)
```

The results are as follows (the buffer size is multiples of the pagesize which is 4KB):

```
4 * 1024 * 1024: 8.3 Gbit/s (for 100MB and 1GB objects)

400 * 1024: 9.1 Gbit/s (for 100MB) , 9.4 Gbit/s (for 1GB)

40 * 1024: 8.3 Gbit/s (for 100MB and 1GB objects)

4 * 1024: 6.9 Gbit/s (for 100MB)
```
So a buffer size attains close to the maximum measured by iperf.

cc @robertnishihara @elibol @atumanov @ericl