feat(graphsync): allow setting of per-peer incoming requests for miners

[rvagg]

@jennijuju to get this started. Exposes graphsync 0.10.3's MaxInProgressIncomingRequestsPerPeer as SimultaneousTransfersForStoragePerClient for storage providers only (the other gs options are exposed for fullnodes/clients too, I'm assuming this is appropriate behaviour).

Will need @hannahhoward's eye, and tests would be nice but I have no idea what that might look like.

[codecov]

Codecov Report

Merging #7578 (d336b0b) into master (690be5b) will increase coverage by 0.32%.
The diff coverage is 100.00%.

❗ Current head d336b0b differs from pull request most recent head 9e7d9af. Consider uploading reports for the commit 9e7d9af to get more accurate results

@@            Coverage Diff             @@
##           master    #7578      +/-   ##
==========================================
+ Coverage   39.48%   39.81%   +0.32%     
==========================================
  Files         653      633      -20     
  Lines       69925    67100    -2825     
==========================================
- Hits        27611    26715     -896     
+ Misses      37567    35780    -1787     
+ Partials     4747     4605     -142     

Impacted Files	Coverage Δ
node/builder_miner.go	94.85% <100.00%> (-0.04%)	⬇️
node/config/def.go	97.41% <100.00%> (+0.01%)	⬆️
node/modules/storageminer.go	63.17% <100.00%> (ø)
node/impl/full/wallet.go	35.89% <0.00%> (-28.21%)	⬇️
extern/sector-storage/storiface/worker.go	53.84% <0.00%> (-22.16%)	⬇️
chain/events/message_cache.go	87.50% <0.00%> (-12.50%)	⬇️
api/v0api/v1_wrapper.go	2.22% <0.00%> (-11.99%)	⬇️
markets/dagstore/mount.go	73.33% <0.00%> (-10.88%)	⬇️
markets/loggers/loggers.go	89.28% <0.00%> (-10.72%)	⬇️
extern/sector-storage/fr32/fr32.go	91.86% <0.00%> (-8.14%)	⬇️
... and 159 more

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 690be5b...9e7d9af. Read the comment docs.

[hannahhoward]

LGTM as long as folks are ok with the slightly confusing behavior of 0 = no per peer limit.

The 0 made sense as a hidden default, but is perhaps a take confusing as explict config. I think we documented it though so it's probably fine?

[jennijuju]

LGTM as long as folks are ok with the slightly confusing behavior of 0 = no per peer limit.

I think its fine as we have similar behavior in sealing configurations as well.

[jennijuju]

@rvagg @hannahhoward is the total amount of SimultaneousTransfersForStoragePerClient bounded by SimultaneousTransfersForStorage ? so for example, if SimultaneousTransfersForStorage is set to 20, and SimultaneousTransfersForStoragePerClient is set to 10 and the SP has incoming dt from 5 clients. does SP will only have 20 ongoing dt across these 5 clients from a first come first serve basis?

[rvagg]

@jennijuju yes, SimultaneousTransfersForStorage is the upper limit regardless. SimultaneousTransfersForStoragePerClient is bound by it (docs in here says that) and your example is correct - capped at 20 simultaneous in total and 10 per dt. Do you think it could be made more clear in the docs here perhaps?

[jennijuju]

Suggested change

	// will have no effect.
	// will have no effect. Total amount of simultaneous data transfer across all storage clients is also bounded by `SimultaneousTransfersForStorage`.

[jennijuju]

@jennijuju yes, SimultaneousTransfersForStorage is the upper limit regardless. SimultaneousTransfersForStoragePerClient is bound by it (docs in here says that) and your example is correct - capped at 20 simultaneous in total and 10 per dt. Do you think it could be made more clear in the docs here perhaps?

thanks @rvagg ! made one small suggestion on the doc - do you think it make sense?

[rvagg]

@jennijuju yep, I've added your words (fairly closely anyway), rebased and squashed this branch so it's up to date and just one commit now.