feat: user roles and permissions

[felangel]

As a user, I want to be able to add collaborators who have different permission levels. For example, I may want to have a single user who has permission to publish releases and patches but have other users have read-only access to view releases, patches, insights, and be able to preview an patch locally.

Currently, if user adds a collaborator, that collaborator automatically gets access to view and modify an app (including managing releases and patches).

[btrautmann]

To anchor this to our ideal setup, I'd describe our end goal as the following:

• Only CI is allowed to publish patches (or more generally manipulate patches assuming deactivating them etc. can be done via CLI). This feels like a "patch manager" role or similar. This would likely look like a token that's stored as a secret and read by shorebird during a publish.
• Collaborators (i.e developers) have a "developer" role that allows them to view anything in the console as noted in OP.

[felangel]

Related issues

• feat: Users expect to have organization/account based access control #1433
• feat: would like to add collaborators who cannot push patches #1337
• feat: share GROUPS of apps with a group of people (organizations / teams) #739

[btrautmann]

@felangel if you feel this has too much overlap with existing issues, feel free to close it as such. I know this sorta spawned out of conversation with myself and @ClaireDavis--neither of us will be offended if we need to subscribe to another issue 😄

[eseidel]

Yeah, more issues isn't a problem. We know we need to do a bunch of work in this area, we've just been a) really busy with iOS and 1.0 and b) waiting until we had more reports from customers (like this one!) so we know we're building the right thing. Thank you!

[eseidel]

This ends up part of #1433 which I think is probably our next big area of work after iOS performance (maybe we'll do asset support before that?)

[eseidel]

Much of this is launched now as part of #739.

Will keep this bug open for adding further permission levels.

We had an explicit request today from a large customer to separate "create a patch" from "send a patch to users" roles.