Provide order: should provide roots asap

[larsks]

I'm running 0.3.8-dev locally under OS X and on a remote server under Linux (x86_64).

I've ipfs add -r'd a local directory. While I can access the resulting objects locally, they are not visible from either my remote ipvs instance or using gateway.ipfs.io.

Locally, I appear to have 59 available peers in the output of ipvs swarm peers, which would suggest to me adequate connectivity but I'm not to ipfs so maybe it doesn't really suggest that.

I've tried the reverse (adding something on the remote server and then trying to access it locally), which also fails.

[larsks]

I see, there's just a looooong delay for new objects to seed across the network, I guess.

[jbenet]

@larsks actually this is a design bug, so i'll reopen this issue. the problem is that currently, we start "providing" as we add content, which means that the last object to be provided is the root. and for huge directories, it's the first object you want seeded.

what we should do is:

• continue providing asap
• prioritize providing "non-leaf" nodes, starting from the root.

desired action: as soon as an add finishes, the root should be provided, followed by the first children, etc.

[Stebalien]

We now do this.