EPIC: Investigate how best to deal with badge traffic issues

### Background:
- The badge as currently implemented generates tremendous inbound traffic to H infrastructure. This traffic increases with each additional browser that has our extension installed. For every page they visit, at least one inquiry is made— regardless of whether that inquiry will generate a zero result (which the overwhelming majority do), or whether the person is even paying attention to the count, and/or is an active user of H.
- Because the badge queries each page the user visits, H is tracking the user’s history - the user therefore has to give up some privacy for this feature.

### User Story:
As a Hypothesis user of the extension, I want to know if there are any annotations on a page (only me, group, public) without having to open the Hypothesis application, so that I can have a quick an easy way of knowing whether a discussion has occured on that page, and I can be more likely to engage with the annotations on the page. Without this capability, I’ll have to turn on the extension and open the sidebar each time I want to see if there’s any activity at all.

### Possible Solutions (as discussed by @seanh @hmstepanek @robertknight)
1. Re-establish an emergency kill switch
-- Blocking the badge requests in nginx
-- Need to build a system that automates turning on/off
-- Add an env variable in AWS config service?

2. Separate badge into its own service (Rob’s “badger” prototype)
-- Assuming the badge functionality stays the same, and the count depends the sum of all the annotations in public +any groups you’re a member of.
-- The badge currently goes through the h database and shared infrastructure w/ other services.

3. Bloom filter
-- Hash of all the URIs that have been annotated. It looks for the hash of the doc you’re on.
-- There are false positives that are likely - saying that there are annotations there when there aren’t - or maybe there won’t be any false positives in practice.
-- Advantage: doesn’t require server side access. Don’t have to create a seperate server.

### Next Steps
- [ ] Determine which solution, or combination of solutions to pursue research of.
- [ ] Implement kill switch if needed
- [ ] Prioritize bade endpoint work in product backlog/roadmap once solution is decided on.

No files, tests, or entry points are named. Compare the emergency kill switch, separate badge service, and Bloom filter options, including traffic and privacy trade-offs. Done means selecting a solution or combination, documenting the research outcome, and defining whether a kill switch or badge endpoint work should follow.

Written by the indexing model from the issue text.