object-patch: Support linking to non-dagpb objects

[magik6k]

No description provided.

[magik6k]

Random fails on jenkins:

not ok 5 - request looks good
#	
#	  grep "POST /api/v0/cat" nc_out
#	

expecting success: 
  test_expect_code 1 grep "api=/ip4" nc_out

Got this one 3 times:

expecting success: 
      ipfsi "$node" name resolve "$name" > resolve
    
Error: Could not resolve name.
not ok 20 - just after publishing: node 3 can resolve entry
#	
#	      ipfsi "$node" name resolve "$name" > resolve
#	

[Stebalien]

not ok 20 - just after publishing: node 3 can resolve entry

Yeah, I've seen that a few times recently. @vyzo?

[vyzo]

think it's related to the new pubsub code and changes that it brought? It really shouldn't affect normal resolutions.

[whyrusleeping]

I think this is a bit risky to do this way. Lets switch on the type, and then explicitly handle the ProtoNode and RawNodes. Then for everything else we can error out.

[magik6k]

Why not allow linking to other types? I actually need this to link to git commits, it works well for my usecase (ipld git helper). (note that it's already possible to do this with dag commands)

[whyrusleeping]

The issue isnt that we don't want to allow linking, but that this operation is supposed to recursively copy a graph from one dagservice to another.

[whyrusleeping]

@magik6k we can change the first argument of this function to accept a node.Node, then skip this check entirely

[magik6k]

done

[ghost]

This should also test resolving the link, i.e. $N1/foo