Revert concurrency flag change

[joshklop]

No description provided.

[codecov]

Codecov Report

Patch coverage: 100.00% and project coverage change: +0.11% 🎉

Comparison is base (1e4e484) 73.60% compared to head (759b51b) 73.71%.
Report is 1 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #1215      +/-   ##
==========================================
+ Coverage   73.60%   73.71%   +0.11%     
==========================================
  Files          70       70              
  Lines        7498     7499       +1     
==========================================
+ Hits         5519     5528       +9     
+ Misses       1522     1518       -4     
+ Partials      457      453       -4     

Files Changed	Coverage Δ
cmd/juno/juno.go	57.31% <ø> (-0.52%)	⬇️
node/node.go	46.61% <100.00%> (+0.81%)	⬆️

... and 3 files with indirect coverage changes

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[omerfirmak]

This is not only for batches. Concurrency limit is shared between all requests.

[joshklop]

This is not only for batches. Concurrency limit is shared between all requests.

Do you mean it is shared between all batch requests or all requests (batch or stand-alone)? Based on my understanding, it appears to be the former. I can adjust the docs to clarify that.

[omerfirmak]

all requests (batch or stand-alone)?

This.

There is only a single pool per jsonrpc.Server. So a batch with N individual requests in it will consume N workers from the pool and each standalone request will consume 1. Since we use a single jsonrpc.Server, the pool is shared between HTTP/WS transports as well.

[joshklop]

each standalone request will consume 1

Does it? Standalone requests are handled in the current goroutine, so we don't take a goroutine from the pool.

[omerfirmak]

each standalone request will consume 1

Does it? Standalone requests are handled in the current goroutine, so we don't take a goroutine from the pool.

Ah, you are absolutely right. I got it all wrong then. Then my assumption about the broken pipe issue was wrong as well. We can lower the default 1024 to something reasonable too. Do you mind doing it in this PR?