Outputs added directories as they are traversed.

[hackergrrl]

This also fixes a bug where adding with -n would prevent directories from
being outputted. Addresses #2530.

Bonus: directories no longer appear at the end of the list for ipfs add --
they're in order! 👯

[hackergrrl]

(I still have some tests to fix up, now that the add order has changed.)

[whyrusleeping]

No. The change to output directories at the end of the add was a conscious decision, files in a directory may be added before or after the directory itself is 'added' so the hash of the directory may change. No order is guaranteed about the stream of objects being added in an add

[hackergrrl]

Ah, this makes sense now. Consider a case like:

$ ipfs add foo/bar foo/baz

We need to create the foo dir when foo/bar is created, but we can't output its hash yet, since after foo/baz is added it will have changed -- so directories definitely need to have their hash computed last.

However, this doesn't mean we must output them at the end: we can still perform a formatting step post-add that will provide a more traditional output structure (subfiles THEN containing dir).

[hackergrrl]

I ended up modifying the existing logic to use MFS for traversal instead of relying on the dag service directly. I had to tweak how mfs.Directory was doing caching to ensure that the children are available after being added by AddNode, but otherwise this went pretty smoothly after I grokked the code structure.

[whyrusleeping]

we'll want to do some type checking here:

dir, ok := adder.mr.GetValue().(*mfs.Directory)
if !ok {
   // errrorrrr
}

root, err = dir.Child(name)
...

[hackergrrl]

🎉 Ready for merge!

[whyrusleeping]

can actually just do return root.GetNode() its a little cleaner looking

[hackergrrl]

Agreed -- changed.

[hackergrrl]

Anything else you need done in here, @whyrusleeping?

[whyrusleeping]

Nope, this LGTM