Update databus polls to honor polling API key's SoR read permissions

[billkalter]

What is the Issue?

Databus subscriptions currently do not honor table read permissions. For example, assume subscription "sub1" has condition alwaysTrue() and is polled by API key "apikey1". Assume apikey1 has the necessary permissions for databus access but the only SoR-related permission it has is sor|read|if(intrinsic("~table","only_accessible_table")). If anyone updates a record in table "inaccessible_table" the update notification and record contents will be available to apkey1 when it polls sub1.

A proper remedy to this requires that each subscription is associated with an API key. This way the fanout process can determine whether the record is accessible not only by the subscription but also by the subscriber before putting the record onto the subscription. Of course, the downside to this is that each subscription must now be polled by only a single user, but realistically this is the only observed use case to-date anyway. Additionally, after much discussion with the team we could neither come up with a use-case nor a satisfactory solution for sharing a databus subscription with multiple API keys with potentially different read permissions.

How to Test and Verify

Follow the example from the issue description: create an API key with limited read permissions, create a databus subscription, and perform updates on records in tables which the API key cannot read. The API key will not be able to read those records directly from the sor module but it will be able to see the records by polling the subscription.

Risk

High, since this impacts multiple systems. Namely,

1. It requires updating the databus implementation to associate an API key owner with each subscription.
2. It requires updating the fanout process to check read permission on each record before placing it on a subscription.
3. The read permission check must be efficient enough not to cause a bottleneck in the fanout process.

Level

High

Issue Checklist

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