De-duping those additions seems like a good idea, but we found out that
in some cases, OME will emit open and closes for streams while they're
still live. De-duping those resulted in streams erroneously being
removed from the live list.
One such scenario is someone trying to "Steal" and already live key. OME
will emit an open and an immediate close as the connection is rejected.
The close was removing the still-live stream from the list.
Fixes#9
For the moment this is a singleton. One access key will let you stream
to any app or stream key. It's denoted in the form of appending a GET
parameter to the URL like `?access_key=foobarbaz`
This at least means someone who knows the stream URL (frex to view it)
won't also be able to stream.
We used to wait until all work in the admission webhook was done to save
out the new list of streams as edited by the webhook. This produces two
issues:
1. It was possible to encounter a race condition if a second webhook
fired while the first was still processing the callout to Discord
2. If the webhook throttle engaged, `handle_notify()` would return
before saving the list out at all
Now we inspect the list, decide what we're going to do, save the new
list out, and then call the Discord webhook as appropriate.
There's a one-second sleep in the old hook, because the Oven API did not
always record the stream change quickly. Sometimes even that was not
enough. This attempts to work around that by managing the stream list
directly.
10,000 hours mucking with `git filter-repo` and no reasonable use-case
found. On the plus side, anyone looking at this and curious what I nuked
isn't missing much. This lived in a monorepo up until about a week ago.
