refactor: find share.Availability abstraction alternative

[distractedm1nd]

The share.Availability interface used in ShareService was a good abstraction to start with, but as the node grows and our services change, we run into more and more issues with its limitations and structure.

Some issues (please add to this list!):

• CacheAvailability is only needed for light nodes after the introduction of eds.Store
• Bridge nodes need an eds.Client to use FullAvailability
• Too much indirection for the value it brings
• Parametrization makes it even more confusing

One proposed solution is to get rid of the interface entirely and instead have multiple implementations of ShareService.

[Wondertan]

• shrex/push required us to extend the SharesAvailable method peer.ID variadic param. This breaks the original beauty of the interface, where we abstracted peering and could implement a single code path for both Historical and Recent Data. Unfortunately, the recent design of data sync splits those into two different code paths, burying down the beauty of the interface. In the long term, we should aim for a single code path for both cases, but we should consider revamping the interface or completely removing it until we design a protocol that allows the single code path.