The sending party may finish setting up encryption and start
sending encrypted packets while the receiving party is still configuring
encryption and expecting unencrypted packets
PiperOrigin-RevId: 549267838
During the destruction of NearbyConnections, Core (which owns ClientProxy) is destructed before ServiceController (which owns EndpointManager), which means any pending tasks on the EndpointManager executor that use ClientProxy will be using
garbage memory. To fix this issue, EndpointManager::DiscardEndpoint will check
for an `is_shutdown` boolean set during ~EndpointManager before accessing
ClientProxy. The assumption is that any accessing of ClientProxy after the
destruction will be invalid.
PiperOrigin-RevId: 532581122
This CL should be a no-op.
Provide better access to the service ID during bandwidth upgrade handling. Notably, 1) have the endpoint channel store its associated service ID, and 2) send the service ID on a connect/disconnect.
The service ID identifies the application, for example, "NearbySharing". In future CLs, we will use the service IDs to better handle bandwidth-upgrade bookkeeping when multiple services are running simultaneously. Specifically, we will better handle reverting a bandwidth-upgrade medium without interfering with other services.
PiperOrigin-RevId: 442019209
Janusz Sobczak