Design an object-oriented SatelliteNetwork that processes a stream of instructions to simulate message propagation and determine report-back order and times. Implement these methods: 1) SatelliteConnected(SatelliteId): Add a satellite node to the network. 2) RelationshipEstablished(SatelliteId1, SatelliteId 2): Add an undirected connection between two satellites. 3) MessageReceived(M, SatelliteId_1, ..., SatelliteId_M): Treat the given M satellites as simultaneously notified at time t=0, then simulate propagation and return the list of (SatelliteId, reportTimeSeconds) ordered by the time they report back to Earth (ties broken by smaller SatelliteId). Simulation rules and constraints: - Forwarding latency: It takes exactly 10 seconds for a satellite to forward a message to one of its direct connections. Forwarding to neighbors is synchronous and atomic per sender: a sender can forward to only one neighbor at a time, each taking 10 seconds. - Forwarding order: Each satellite forwards to all direct connections it has not already notified, strictly in increasing SatelliteId order. - Single effective notify: Once a receiver is notified (by any source), it is considered notified; no further notification attempts change its state. However, concurrent attempts from other senders to notify the same receiver still each consume 10 seconds of the sender’s time. - No immediate back-edge: A satellite never notifies the satellite that most recently notified it. - Processing delay: After a satellite’s direct connections are all notified (from its perspective and per the ordered forwarding it performs), it waits 30 seconds, then it processes the message and reports back to Earth. - Reporting tie-breaker: If two satellites finish processing at the same time, the one with the smaller SatelliteId is considered to arrive first. - Multiple messages: Each call to MessageReceived represents a new message whose initial notified set is the provided satellites at t=0. Clarify whether propagation state resets per message (typical) or persists; implement accordingly and justify. Output and complexity: - MessageReceived should return a stable ordering of (SatelliteId, reportTimeSeconds) for all satellites that become notified in that propagation, ordered by increasing report time with SatelliteId tie-breakers. - Describe and justify your data structures (e.g., adjacency lists with sorted neighbors, event queue/simulator, per-node state with first-notify time, sender schedules), the event scheduling strategy (e.g., priority queue on next-available time and notify events), and the time/space complexities in terms of V (satellites), E (relationships), and degree distribution. Edge cases to cover: - Disconnected components; satellites never reached should not appear in the output. - Multiple concurrent attempts to notify the same target; ensure only the earliest arrival sets its notify time while all senders still incur 10 seconds. - Large hubs with many neighbors and the impact of strict SatelliteId ordering on timelines. - Re-entrant calls to MessageReceived with overlapping or disjoint initial sets.