refactor(network, dht): NET-1392 rename source to remote in appropriate places

[juslesan]

Summary

Renamed references from source to remote in appropriate places. Using the source/target pattern makes sense if there is a need to indicate clearly who is sending and who is receiving. If the sender and receiver is already implicitly known it makes more sense to use remote/local

Future improvements

• Go over places where the source naming convention is used.
  • For example: In the routing wrappers the source is called sourcePeer. It could make more sense to name it just source. This holds true for any other places where we use ie sourcePeerDescriptor. As the type is known there is no need to include it in the name.
• Rename source to originator? IMO this is not a necessary change since both words have the same meaning in this context

[linear[bot]]

NET-1392 unify naming between remote/local and source/target patterns

[juslesan]

@teogeb

The Linear ticket defines, that "If there is an operation such as an RPC request where there are two parties involved, it makes sense to use the remote/local pattern". Does that apply for these classes/interfaces: -DhtCallContext -DhtRpcOptions -most/all simulator classes And for these protobuf entities: -Message -HandshakeRequest -HandshakeResponse

That depends on if the remote and local party are known for a given operation in the network. Sometimes only the source and destination are known at a given point in transport. In all of these examples the remote and local are not necessarily known.

Should take a closer look at the differences between incomingSourceDescriptor and sourceDescriptor