Seems that folk are having issues with uploading 0-byte files from
Windows agents. This effectively removes the support for Windows for
uploading from named files that, due to `isFIFO` returning `false` on
Windows for named pipes created using MSYS2's `mkfifo` command, resorted
to checking if the file size is 0 - a common trait of named pipes.
See https://github.com/actions/upload-artifact/issues/281
Named pipes report file size as 0, which leads to reading the whole
content into memory (0 is less than 64K). This adds additional check to
make sure that the passed in path is not a named pipe, and in that case
opts for the create-temp-file-to-gzip code path.
When running on GitHub Actions infrastructure on `windows` node, named
pipes can be created using `mkfifo` from MSYS2. In that case `fs.Stats`s
`isFIFO()` returns `false`, and not `true` as expected. This case is
detected by `process.platform` being `win32` and the passed file having
length of 0.
As a side note, when MSYS2's `mkfifo` is run, a pipe file is created:
```
prw-rw-rw- 1 User None 0 Mar 31 12:58 pipe
```
If `fs.stat` is invoked at this point `ENOENT` error will be thrown. As
soon as the pipe is written to, this pipe file is replaced by two same-
named files:
```
-rw-r--r-- 1 User None 0 Mar 31 13:00 pipe
-rw-r--r-- 1 User None 0 Mar 31 13:00 pipe
```
And at this point `fs.stat` `isFIFO()` returns `false`. Even though the
file acts as a named pipe.
