Replace FTNetworkTracer with observer middleware

[ssestak]

Refactor network observation mechanism from a single tracer to a flexible observer protocol. This change replaces the concrete FTNetworkTracer dependency with a new NetworkObserver protocol, allowing for multiple custom observers. The URLServer now supports an array of observers that receive lifecycle callbacks for each request.

Key Features:

• Decoupled Network Observation: Replaced the concrete FTNetworkTracer dependency with a protocol-oriented NetworkObserver, enhancing flexibility and extensibility.
• Support for Multiple Observers: The URLServer now manages an array of NetworkObserver instances, enabling different modules to independently observe network events.
• Contextual Callbacks: The new NetworkObserver protocol uses an associatedtype Context to pass correlation data (e.g., request ID, start time) between willSendRequest and subsequent completion callbacks.
• Improved Testability: Dedicated NetworkObserverTests and a MockNetworkObserver demonstrate better test isolation and clarity.
• Simplified Package.swift: Removed the external dependency on FTNetworkTracer.

Changes Summary:

Feature	Before (Legacy)	After (New)
Observation Mechanism	Single FTNetworkTracer?	Array of [any NetworkObserver]
Dependency	External FTNetworkTracer	Internal NetworkObserver protocol
Context Handling	Manual requestId, startTime	associatedtype Context managed by observer
Test Coverage	NetworkTracerIntegrationTests (deleted)	NetworkObserverTests (new)

[ssestak]

@mkj-is Hey I tried to implement the recommendation you pointed out in this comment. I would like to know your opinion on this if you have time.

[mkj-is]

@mkj-is Hey I tried to implement the recommendation you pointed out in this comment. I would like to know your opinion on this if you have time.

Looks much better.

I do not understand the need for the context and generating artificial request ID. This could be handled by using X-Request-ID header or similar solution. If you opt to use native URLSessionTaskMetrics you do not need to keep the reference to original request to calculate the difference from the start time to current time and can get more granular data.

[ssestak]

Looks much better.

I do not understand the need for the context and generating artificial request ID. This could be handled by using X-Request-ID header or similar solution. If you opt to use native URLSessionTaskMetrics you do not need to keep the reference to original request to calculate the difference from the start time to current time and can get more granular data.

Thanks for the feedback and for pointing me to URLSessionTaskMetrics - I wasn't familiar with that API before.

On Context and request ID:
Keeping it allows observers to work independently without modifying the API flow. Users who don't need correlation can use Void as Context.

On URLSessionTaskMetrics:
You're right that URLSessionTaskMetrics is the proper solution for accurate timing. For basic duration logging though, Context is sufficient and keeps everything in one observer file without additional setup.