Connection timeout defaults to 120 seconds, but requests run forever

Hey all,

I guess this is more about setting some sensible default ini settings more than anything. We're using HHVM on Ubuntu with Apache 2.4 and FastCGI.

If you run the following example script with the default config on ubuntu, there are two weird side effects:

``` php

```

The side effects are:
- After 120 seconds, there is a 503 error sent to the browser and the following in apache's error log:

```
[Mon Dec 01 14:45:27.880594 2014] [proxy_fcgi:error] [pid 26142:tid 140118906251008] [client 127.0.0.1:52699] AH01067: Failed to read FastCGI header
[Mon Dec 01 14:45:27.880738 2014] [proxy_fcgi:error] [pid 26142:tid 140118906251008] (70014)End of file found: [client 127.0.0.1:52699] AH01075: Error dispatching request to :
```
- Also, the request still executes indefinitely, as indicated by `hhvm.log`:

```
running for 409 seconds
running for 410 seconds
running for 411 seconds
```

The workaround we've found is to add these two statements in `server.ini` or `php.ini`:

``` ini
hhvm.server.connection_timeout_seconds = 300
hhvm.server.request_timeout_seconds = 300
```

This will boost the max timeout to 300 seconds. Obviously you can set this to whatever you want.

From the looks of the config, `hhvm.server.request_timeout_seconds` is default to `-1`, so not setting this in the server options file will cause a number of dead threads on long running scripts.

Conversely, not setting the `hhvm.server.connection_timeout_seconds` will cause the fastcgi connection to error out after 120 seconds and return a 503 error after that time, but the script will continue to execute up to `request_timeout_seconds` time, or indefinitely if it's not set.

There is also no log entry for when `connection_timeout` is hit, except for the EOF message from apache.

For request_timeout, it looks like it hits an exception:

```
Fatal error: entire web request took longer than 300 seconds and timed out in ../test.php on line 10
```

I guess the proposed changes would be as follows:
- Throw a proper exception when connection_timeout is hit, so it logs something appropriate, otherwise this is actually a very hard thing to track down.
- Set a sensible default for request_timeout. I could see this becoming a security concern if threads hang around forever.