refactor(share): GetShare -> GetSamples

[Wondertan]

Samples were requested individually rather than grouped. This was causing issues for Bitswap in the mode where each request is a distinct session, so the solution is to start grouping those as we originally planned.

Mainly removes GetShare and introduces:

GetSamples(ctx context.Context, header *header.ExtendedHeader, indices []SampleIndex) ([]Sample, error)

And introduces SampleIndex with helper funcs.

The current state of the PR unblocks me and allows me to iterate further on Bitswap issues, while the remaining TODOs still need to be finished.

TODOs:

• eds.Accessor should take the new shwap.SampleIndex as param in Sample method
• !Add GetSamples to the ShareModule.
  • Need to decide which release we want to put this breaking change in
• Godoc new things
• Fix remaining tests
• Rebase
• Decide on whether SampleIndex should be an index or a tuple.

---

🎱 mb blonks certified

[walldiss]

Yes, it is a 1D index. I think it's worth having it for convenience, as there are still cases where 1D is used. It is not necessary internally but externally. Users, like Diego and Rollkit operated with index. E.g Rollkit fraud proofs point to 1D index, rather than a coord.

Well, we don't have any 1D indexes in our code base internal API, not in external json-rpc API we have. Introduction of 1D index brings lots of conversion from 1D to 2D and back here and there as we can see in this PR. Which suggests that we don't need it anywhere. We don't really need to introduce the second way to express same thing.

Diego and Rollkit operated with index

Do you know why they use it instead of 2D? Might be aswell be historical or random decision. Perhaps we should not introduce additional 1D index unless there is reason to have it

[Wondertan]

We should keep 1D convenience methods, while we default coordinates tuple.

[Wondertan]

Approving

[walldiss]

There is a problem in cascade getter. If any of requested samples fail, it will retry with full sampleCoordinates set with next fallback getter, throwing away all found samples. There is no proper support added in this PR right now. It would technically work with current setup because bitswap getter is the last, but it will misbehaive in any other case.
If left as is it may become a huge footgun and nightmare to debug later.

[walldiss]

There is a problem in cascade getter. If any of requested samples fail, it will retry with full sampleCoordinates set with next fallback getter, throwing away all found samples. There is no proper support added in this PR right now. It would technically work with current setup because bitswap getter is the last, but it will misbehaive in any other case.
If left as is it may become a huge footgun and nightmare to debug later.