docs: add discovery spec for shrex

[vgonkivs]

Added a specification for the peer discovery in shrex.

Rendered

[codecov-commenter]

Codecov Report

✅ All modified and coverable lines are covered by tests.
⚠️ Please upload report for BASE (shrex_spec@1751a5c). Learn more about missing BASE report.

Additional details and impacted files

@@              Coverage Diff              @@
##             shrex_spec    #4516   +/-   ##
=============================================
  Coverage              ?   35.41%           
=============================================
  Files                 ?      304           
  Lines                 ?    24297           
  Branches              ?        0           
=============================================
  Hits                  ?     8605           
  Misses                ?    14745           
  Partials              ?      947           

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

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[Wondertan]

First pass. Please add a link to the rendered markdown to see the rendered diagram.

Directionally, the spec is alright. My main concern is that implementation details are mixed into the part of specification. Particularly, parts that have to be specified in main body of the doc with words are somewhere hidden in implementation details in code, like tags, params and rationale for them.

[renaynay]

We should make it very clear that from a discovery standpoint - full and bridge nodes are identical in the services they can provide to light nodes and that is the rationale for both advertising under full tag. I think even though we specify that full nodes are deprecated, it's a bit confusing to follow in this doc.

Also mention the connectedness of the peers and what kind of connectedness we expect peers to have that we maintain in our limited peer set. Make sure to specify that the criteria for staying in the limited peer set is that it is actively connected to the node at all times, and once that changes, that we kick peer + discover new one that meets connectedness criteria.

[renaynay]

one thing is we need to mention connectedness status and that the peers in the limited set must active connections - otherwise they must drop the peer for which connectedness changes to anything but connected and discover a new active connection.

[renaynay]

Besides these comments, I think it's pretty good coverage of discovery!

[renaynay]

sentence here is duplicated

[renaynay]

The discovery service maintains a limited peer set in which all peers MUST have active connections with the host service. When connectedness changes from active to any other state, the peer MUST be immediately dropped and replaced through new discovery. The dropped peer SHOULD be added to a cache with backoff so it will not be prematurely re-connected to through discovery.

[renaynay]

we can use active here to be clear, as we use it elsewhere.

[vgonkivs]

removed a limited set everywhere and changed to Active Set in glossary

[walldiss]

Need to add network level params for dht configuration (per node type etc)

[Wondertan]

When rendered, this looks like a single paragraph. Also the overview is not section to put DHT configuration and modes.