fix: store: expCid vs actualCid guard

[i-norden]

In the BasicIpldStore.Put() method we have guards that check if the object's provided CID equals the one derived internally. Here and here.

One problem is that these guards first include a check to see if expCid != cid.Undef and this will never be the case because expCid is only assigned locally in this if block- no assignment to expCid escapes or occurs outside that block so it will always equal cid.Undef in these guards.

The other behavioral problem with these guards, I think, is that they are placed after the IPLD block has already been written to the underlying blockstore. So the IPLD block could be written to the blockstore with a CID that the caller does not have. If this is the correct positioning of the guards because the IPLD block should be written with the derived CID even if it does not match the provided one, in that case I think it would make sense for the method to return the CID it wrote to the blockstore with instead of returning cid.Undef.

[welcome]

Thank you for submitting this PR!
A maintainer will be here shortly to review it.
We are super grateful, but we are also overloaded! Help us by making sure that:

• The context for this PR is clear, with relevant discussion, decisions
  and stakeholders linked/mentioned.

• Your contribution itself is clear (code comments, self-review for the
  rest) and in its best form. Follow the code contribution
  guidelines
  if they apply.

Getting other community members to do a review would be great help too on complex PRs (you can ask in the chats/forums). If you are unsure about something, just leave us a comment.
Next steps:

• A maintainer will triage and assign priority to this PR, commenting on
  any missing things and potentially assigning a reviewer for high
  priority items.

• The PR gets reviews, discussed and approvals as needed.

• The PR is merged by maintainers when it has been approved and comments addressed.

We currently aim to provide initial feedback/triaging within two business days. Please keep an eye on any labelling actions, as these will indicate priorities and status of your contribution.
We are very grateful for your contribution!

[rvagg]

Yeah, these both look like good fixes to me but it has me wondering how and why you're using these and bumping into these paths? Mostly this package is considered semi-deprecated—although still widely used, it's not a package I'd reach for to write anything new. Tho it should be efficient and work at least!

[i-norden]

Hey @rvagg thanks, I have some follow up PRs that will shine some light on why this was ran into. We are updating and using this package for forks of go-hamt-ipld and go-amt-ipld that expose parallel traversal methods (based on filecoin-project/go-hamt-ipld#103). I understand many of the repos in the chain of dependencies we are updating are being deprecated and don't expect the more substantial changes to be merged necessarily- we can continue to maintain forks- but I figure I should submit the PRs for visibility in case there is more general use/interest and in case there is useful feedback.

[lidel]

@rvagg this came up during triage: what is next for this PR? is there anything that needs to happen before it can be merged? thanks!

[rvagg]

thanks for the ping @lidel this is fine to merge, done