Fix busy loop in various IO functions on some platforms

Don't include STREAM_AWAIT_ERROR in stream_await call

Summary:
STREAM_AWAIT_ERROR is a return code, not an event type.

This is fine on some Linux systems, but on others and MacOS it returns instantly, leading to busy loops.

This API isn't as typed as we'd like as it's older than enums. Being replaced
with HSL IO.

Reviewed By: alexeyt

Differential Revision: D14142241

fbshipit-source-id: d5f9be7b5e68893fde113473c6a5d9adf2394abf

Fix busy loop in various IO functions on some platforms

v3.30.3

Add branch aliases so travis can resolve the version constraints

Support HHVM v4.0.0

This release:

• supports and requires HHVM v4 and HSL v4
• no longer includes Regex\ as that is now part of the main HSL

Safer implementation of request_input()/output() in CLI mode

As an implementation detail, prior releases used php://input and php://output in all modes.

This release changes to use php://stdin and php://stdout instead, as php://input and php://output are not "real" FDs, which can lead to observable differences, e.g.:

<?php
$f = fopen('php://stdin', 'r');
stream_set_blocking($f, false);
fgets($f);
var_dump(feof($f)); // false for php://stdin, true for php://input

Target HHVM 3.30

This release:

• targets HHVM/Hack 3.30.0
• no longer includes PseudoRandom\ and SecureRandom\ as they are included in the main HSL

v3.30.0 was incorrectly tagged.

API consistency for STDIO handles

This release converts the new request/server IO functions from camelCase to under_scored.

Re-release 3.29.x

This is what was meant to be 3.29.3:

Replace stdout/stderr/stdin with {request,server}_{input,output,error}

• this provides access to POST data and HTTP response bodies
• this provides a consistent API regardless of mode: generally, request_input and request_output should be used.

Replace stdout/stderr/stdin with {request,server}_{input,output,error}

• this provides access to POST data and HTTP response bodies
• this provides a consistent API regardless of mode: generally, request_input and request_output should be used.

IO and Filesystem namespaces

This release:

• adds the HH\Lib\Experimental\{IO, Filesystem} namespaces
• supports typed user attributes (experimental feature in 3.29)

IO and Filesystem

These namespaces are focused around
async IO, using several interfaces:

• IO\Handle
• IO\ReadHandle
• IO\WriteHandle

For 'on-disk' files, there are extended by:

• Filesystem\FileHandle
• Filesystem\FileReadHandle
• Filesystem\FileWriteHandle

These interfaces are not used for other handles that are considered 'files' by Unix, such as pipes, and STDIN/OUT/ERR.

IO handles can currently be obtained by:

• Filesystem\open_read_only (and open_read_only_non_disposable)
• Filesystem\open_write_only (and open_write_only_non_disposable)
• Filesystem\TemporaryFile
• IO\pipe_non_disposable()
• IO\stdout(), IO\stderr(), and IO\stdin()

Temporary Files

Temporary files are currently write-only, due to not supporting read-write file access yet. The most common pattern we see is generating
a temporary file to pass to another process; this is supported by:

await using ($tf = new Filesystem\TemporaryFile()) {
  await $tf->writeAsync("Foo\n");
  await $tf->flush();
  call_some_subprocess($tf->getPath()->toString());
}

Passing handles

We recommend using:

function writesToHandle(<<__AcceptHandle>> IO\WriteHandle $handle) {
  // do stuff
}

This will work with both disposable and non-disposable handles. The same pattern can be used for IO\ReadHandle.

Design ideas

• multiple writers for a single stream makes sense; for protocols that allow request multiplexing (such as FastCGI, HTTP2, and LSP), having an awaitable handler per request,
  it is a reasonable model to have a separate async handler for each request that writes back to the same handle
• this requires queuing: if two separate handlers write messages larger than the buffer size, the two messages must not be interleaved
• reads at least must be a separate queue: using multiplexing as an example again, if a huge response is being written, this shouldn't block starting the handler for a new request
• in general, multiple readers for a single handle don't make sense: this is only truly workable if dealing with fixed-length messages
• for this reason, reads are always unqueued

Future work

This can be followed in #21. The biggest areas are:

• add read-write file opens
• add support for other forms of handles, such as sockets
• consider adding support for a disposable pipe() (currently not supported due to being unable to return a tuple of disposables)

Read-write file opens

We're unsure if the usual approach of allowing both reading and writing on the same file descriptor is best in an API centered around async IO: read and write have significantly different behavior, especially around ordering.

We are currently evaluting if it might instead be better for read-write file modes to always dup the file descriptor, and
have truly independent read and write paths for the same file. We believe this would largely be transparent and avoid
complicated bugs - but, it would be at the cost of both the dup call, and using additional file descriptors. We welcome
feedback on this point.

We would do this for files, but we are not aware of a reason to do this for sockets (or a way that doing so would be observable),
due to sockets not supporting operations such as seek.

Add Experimental\Str\Utf8 namespace, support (and target) HHVM 3.29.x

v3.29.0

Target HHVM 3.29