Remove uniqueness constraint from databus subscription name

[billkalter]

What is the Issue?

One of the changes introduced in #19 is that each databus subscription is now associated with a single API key owner. With this change the unique identifier for a subscription effectively changed from (name) to (name, API key). However, the system still requires that each subscription name is unique system-wide.

Emo should be changed to permit different API keys to have subscriptions with the same name. The largest barrier to this is that the underlying event channels names are the subscription names. This would have to be changed to include the owner's internal ID as part of the event channel name. There would also have to be a way to grandfather in events from the existing databus event channels.

Recommend changes:

• Change databus subscription names to be unique within the scope of the owning API key
• Change databus permissions to be boolean on the ability to create subscriptions, since restricting subscription names would no longer serve a purpose without the possibility for subscription collisions.
• Migrate databus event channel names to be unique by subscription name and owner internal ID.

How to Test and Verify

1. Check out the project
2. Start EmoDB
3. Create two API keys
4. In each key create a subscription with the same name and different conditions. With the current Emo version the second create will return a 403 exception with the reason "Not subscriber".
5. Create several tables and documents, some of which match the subscriptions for both keys and some for only one.
6. Poll both subscriptions and verify each received the correct events.

Risk

This is a fairly high risk change because it fundamentally changes one of the central pieces of the Emo architecture. As previously noted there needs to be a smooth migration from old to new event channel names with no downtime and without losing any preexisting events in the old channels.

Level

High based on the areas touched by this change, even though the effort and scale of implementing the change may be lower.

Issue Checklist

• Make sure to label the issue.
• Well documented description of use-cases and bugs.