Remove emitting SD event for receiving URI data update

[bohhyang]

Summary

We recently added emitting SD status update receipt event for receiving URI data updates (previously only add/remove URI will emit the event). Turns out that increased the event volume a lot ---- apps like seas do URI data updates very frequently (weight, uri specific properties, etc.) and have both large fleet size and large audience group (hence huge fanout). Considering that having the events for add/remove URI is good enough for analyzing SD end-to-end propagation latency, and including the URI data updates could cause unmanageable pressure on the data analysis pipeline, such as Kusto query, inlogs, etc, we could exclude the URI data updates from emitting events.

Testing Done

Updated existing tests.

[brycezhongqing]

LGTM.

One thought from my side is:
If we want to keep update event for URI to analyse later, we may could do sample like only emit first 10 elements.

[bohhyang]

One thought from my side is: If we want to keep update event for URI to analyse later, we may could do sample like only emit first 10 elements.

The volume of Up/down status change is already huge and being sampled in query analysis actually. Adding Uri data update was just to be accurate but the volume could become unmanageable.