## Goal

This is the initial PR for sending network requests as spans. 

- Removed recordAndDeduplicateNetworkRequest. 

This was used in HttpURLConnectionDelegate to avoid logging network requests with the same call ID. It is still required, but we will address it differently in the following PRs. For now, we will use the same method as the rest of the requests.

- logNetworkError and logNetworkCall did essentially the same. We will move that logic to the logging service so we don't bloat EmbraceImpl

- getNetworkCallsSnapshot won't be used anymore, as we will record spans directly when they get to the logging service. We won't need to expose them when the session ends.

- Stop looking for network logs in PerformanceInfo. Removed "nr" from session-end.json. We won't be sending network requests there anymore.

- Updated tests to use the new APIs

## Goal

Delete getNetworkCallsSnapshot, and some private variables used by it.

…iant attributes (#747)

## Goal

This will be used in EmbraceNetworkLoggingService to map from an EmbraceNetworkRequest to the correct span attributes.

We verified with backend that removing null attributes would cause no issues, so we are using toNonNullMap()

- Record network requests as spans.

- Consolidate logNetworkCall and logNetworkError methods

EmbraceNetworkLoggingService had two methods: logNetworkCall and logNetworkError. They were both doing essentially the same, but with a different NetworkCallV2 object: strip the URL, sanitize the TraceId, logging the networkCapturedData, and processing the network call.

We don't need a NetworkCallV2 object anymore, and the EmbraceNetworkRequest is the same for both network call and network error, so we can just use one method.

- Remove unused methods.

### Questions:
- Why do we need to strip the URL? 
- Why are we stripping the URL for the span, but not for the networkCapturedData?

## Goal

Extracted the logic for counting domain limits to another class. This will allow us to test it more thoroughly in the future, as we detected some inconsistencies. It also keeps the NetworkLogging service cleaner. 

### Questions: 
- Shouldn't we ignore domains that can't be parsed for networkCapturedData too?
- Shouldn't we also track limits for networkCapturedData?
- Should we synchronize on another object now that we don't use callsStorageLastUpdate?
- All of the IP address domains fall under the same limit? Is that correct?

## Goal

Added unit tests for EmbraceNetworkLoggingService

Many of the existing tests will be moved to the DomainCountLimiter tests in a following PR