feat: add affected_by_radius to content key

[morph-dev]

What was wrong?

We currently have no way to differentiate between content that:

• is affected by distance from node_id (i.e. non-ephemeral history + state)
• is not affected by distance from node_id (i.e. ephemeral history + beacon)

This affects how we:

• decide whether to accept and store content
• select peers to ask for content (during find_content)
• select peers to gossip content to (both during gossip and poke)
  • we don't do random content correctly at the moment

How was it fixed?

Added affected_by_radius function on OverlayContentKey trait.
This PR sets up ground work for implementing most missing functionality, which can be split into 3 main categories that will be done in a followup PR:

• storage should be flexible enough to handle this case (PR ready: feat: subnetwork stores should use affected_by_radius #1840 )
• bridge's census should respect this when selecting peers (PR ready: feat(bridge): census should use affected_by_radius #1841 )
• make overlay_service (including kbuckets) able to support both type of content (work in progress)

To-Do

• Clean up commit history and use conventional commits.

[KolbyML]

looks good