pre-populate required arguments from request body

[Stebalien]

This way, we can always assume that indexing a required argument works.

Also:

• test that the command tree doesn't have any obvious bugs (duplicate options, arguments in the wrong order, etc).
• simplify the usage ParseBodyArgs.

fixes #4823

[Stebalien]

This looks bad:

ok 78 - 'ipfs add -r --raw-leaves' output looks good

expecting success: 
    { echo "$MARS"; echo "$VENUS"; } | ipfs cat >actual
  
ok 79 - ipfs cat accept many hashes from built input

expecting success: 
    cat mountdir/planets/mars.txt mountdir/planets/venus.txt >expected &&
    test_cmp expected actual
  
> diff -u expected actual
--- expected	2018-03-17 21:04:04.055381963 +0000
+++ actual	2018-03-17 21:04:04.043382082 +0000
@@ -1,2 +1 @@
 Hello Mars!
-Hello Venus!

not ok 80 - ipfs cat output looks good
#	
#	    cat mountdir/planets/mars.txt mountdir/planets/venus.txt >expected &&
#	    test_cmp expected actual
#	  

[Stebalien]

So, the problem here is that the client is reading off one arg and then forwarding that to the server. However, I've replaced Files with nil so we don't forward the rest to the server.

[Stebalien]

So, the question here is, should we check the arguments on the client? Probably but, in that case, we're going to be splitting them (passing one via the query string and the rest via the body).

[whyrusleeping]

we're going to be splitting them (passing one via the query string and the rest via the body).

This actually seems reasonable. It moves us towards having the requirement that all required arguments are specified via the query string, and the body is only used for optional/variadic args

[whyrusleeping]

However, I've replaced Files with nil so we don't forward the rest to the server.

Wait up, i must have missed this in the CR. We should just replace files with the next file.

[Stebalien]

Blocked on ipfs/go-ipfs-cmds#83

[whyrusleeping]

thats a much better error message.