add View() to all the various blockstores.

[raulk]

😫

[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!

[willscott]

the semantics that if a viewer is set, then the calls to View will only run View on items that are in the cache is not fully intuitive.
Is there a reason not to attempt to go back to the underlying store when not cached?

[Kubuxu]

Here the cache responds that it has seen this element and it was confirmed to not exist (cache returned ok && !has).

[Kubuxu]

We do the same in Get if you look few lines lower.

[raulk]

I think naming is the problem. hasCached naturally read as: "is this item in the cache?" instead of "check if the item is in the has cache".

@willscott this just short circuits the view if we know that the item doesn't exist, because we have a cache entry for it, and it's negative.

[raulk]

@willscott @Kubuxu any more concerns here? Can we move forward and release this, to integrate downstream with a nice version number?

[willscott]

One comment, but I don't see problems with this as-is

[Stebalien]

General process note: for interface changes like this, try to get a signoff from the TL (@aschmahmann in this case) as it may interfere with other plans. I believe this change is safe (and long requested...) but it's still best to be safe.

(otherwise, this has been a long time coming and I'm really excited to see how we can use this in go-ipfs to reduce our memory footprint)