Add output to stdout feature to encode mode and input from stdin to decode mode

[darrenldl]

This can be done by introducing an alternative stream oriented block arrangement scheme

• Add metadata blocks with partial information at front and back
• Metadata blocks at front carry the main stats and user parameters (FNM, SNM, FSZ, FDT, SDT, RSD if applicable, RSP if applicable)
• Metadata blocks at the end carry only the hash of file (HSH)
• For Metadata blocks at back
  • For a data shard count of M, parity shard count of N, all (M + N) blocks would just be the same copy of the metdata block
• Burst error resistance level is forced to be 0 in this scheme, i.e. no blocks interleaving

For encode mode, this scheme is only used if output is set to stdout

For decode mode

• In file input mode, if HSH is missing at front blocks, then check if any back blocks of same UID are present to extract HSH (scan from back to front for (M + N) * B blocks)
  • This is to allow decoding in case user stores the output from encode mode into a file instead of feeding into blkar directly
• In stdin input mode, if HSH is missing at front blocks, then wait for back blocks to appear
  • This is to allow decoding in case user feeds a container using the file oriented scheme

[darrenldl]

This requires a ridiculous amount of effort it seems, at which point it'd be easier to just write a FEC tunnel for transferring files with FEC protection.

Progress is tracked at branch dev-stream-on-hold as archive, not planning on any further development in this direction.

[darrenldl]

Reopened for consideration.

Might be doable with minimal effort by not skipping HSH entirely.

[darrenldl]

Seems better to implement this functionality as stream_encode and stream_decode modes.

In the two modes, metadata blocks are skipped entirely, and RSD, RSP have to be entered manually.

[darrenldl]

Putting features on hold indefinitely.