docs: change gossip rpc return to accepted count instead of offered count

[KolbyML]

Currently portal_historyGossip returns the amount of nodes we offered the content to but this metric isn't very useful as for all we know the nodes it offered the content to could be dead or even worse didn't accept the content in the first place.

That is why I propose we switch portal_historyGossip to return the amount of nodes that accepted the content instead. This idea was taken from Jason Carver in Trin chat on the Portal Discord. I ended up implementing it on Trin and it was 1000 times easier to know what was going on where before I would see a number 8 half sometimes the content would be accepted by 0 nodes and then it was hard to even know if gossip did anything.

If portal_historyGossip gossip's to 8 nodes and 0 nodes accept the content. At that point it doesn't matter if portal_historyGossip returns 8 or 8000 the number doesn't say anything if none accepted it.

[KolbyML]

@kdeme @carver @pipermerriam ping for review

[kdeme]

It's definitely more useful to know the amount of accepted instead of offered. (Just as it would be even more useful to know the amount that actually successfully transferred it over uTP), so in general I'm fine with this change, but ...

To add this into fluffy is however very invasive as we add all offers to an asynchronous queue of offers to be done. There is currently no code path back to deliver the result of those offers.
So it is not something I'll probably add to Fluffy any time soon (if ever). It will also make the call much slower (especially when timeouts). We track the offer/accepts success rate with metrics. Which of course isn't that useful when debugging 1 specific piece of content that fails, but more interesting in the scale of total amount of offers vs accepts. In the past, any debugging for 1 specific piece of content I've just done by looking at the logs (after all, it is enough to look at 1 node for this), an that was sufficient for me (you want to any how know if the content got actually transferred or not).

My suggestion here would be to leave the offered number of peers in the GossipResult as is, and add an optional accepted number of peers in the GossipResult. That way it is easier to stay spec compliant and clients are free to implement this or not.

[pipermerriam]

Is this still relevant? What should happen here?

[KolbyML]

No i will close it

[KolbyML]

We have trace_gossip in trin but I don't think all clients should be required to implement it