Remove limitations preventing client-server capture mode

[dustin-lunarg]

The capture layer currently writes directly to a file. An option should be added for a client-server mode, where the layer acts as a client that transmits data to a server, similar to the current vktrace.

[per-mathisen-arm]

What is the advantage of doing this over saving the file locally on the device? I've been using the local file approach for many years with apitrace/patrace and never seen an advantage from the network streaming solution of vktrace.

[dustin-lunarg]

The client-server mode would be intended for capture scenarios with limited disk space or limited file system access on the capture device. It would be an optional mode, disabled by default. The current method of saving the file locally would remain the default.

[bradgrantham-lunarg]

Adding some kind of network functionality to GFXReconstruct may be out of scope. However, we know we currently use fseek on captures in some processing scenarios. In order to enable e.g. streaming capture files to an Android device that would be too large for the device's filesystem or just so that the copy step can be skipped, we should get rid of any limitation that prevents receiving a stream for replay or one of the tools.

[andrew-lunarg]

An implementation note. Components which have hardcoded writes to files could be changed to stream to our existing OutputStream, and at the top level of tools like optimize, they could be given a FileOutputStream (I have a FileNoLockOutputStream on a branch I hope to land soon) as a first step in incrementally moving over to our streaming future. Later additions of possible NetworkOutputStream, USBDebugIfaceOutputStream, ..etc. would then have a clean place to plug in. Thankfully we already use the streaming interface for capture of both DX12 and Vulkan.

framework\util\output_stream.h
framework\util\file_output_stream.h