Add Enterprise Channel in DevHub

[chrstinalin]

Relates to mozilla/addons#14849

Description

Adds an Enterprise channel to Devhub.

Testing

Enable the enterprise-channel waffle switch.

Themes

1. Themes cannot/do not have the enterprise option.

Extensions

1. Create an enterprise extension (i.e has browser_specific_settings: { gecko: { admin_install_only: true } } in its manifest). On lint, listed/unlisted channels should reject this add-on. The enterprise channel requires it.

2. The source code submission page is skipped for enterprise add-ons.

3. The add-on is subject to automatic approval and not flagged for human review.

4. Has a review page but no listing page, similar to unlisted.

5. Once the enterprise channel is used, new versions must also use the enterprise channel (i.e cannot be listed or unlisted). The user does not have the option to use listed or unlisted.

6. Vice versa, when listed/unlisted are used, the enterprise channel is no longer available. (See: Block Non-Enterprise Versions when Enterprise Version is Uploaded #25186 for replacement)

Checklist

• Add #ISSUENUM at the top of your PR to an existing open issue in the mozilla/addons repository.
• Successfully verified the change locally.
• The change is covered by automated tests, or otherwise indicated why doing so is unnecessary/impossible.
• Add before and after screenshots (Only for changes that impact the UI).

[nothingrandom]

[query]

From the PRD

Once the enterprise channel is used for an add-on, block listed and unlisted versions for that add-on automatically after 90 days. This should be called out in the UI when selecting the enterprise channel for the first time.

The comments on this item, also suggest an unresolved conversation of a) is this correct or b) should a user only be able to select enterprise on first submission (denying any migration of existing)

[chrstinalin]

@wagnerand-moz Do you have any thoughts on this?

[chrstinalin]

In terms of "for the first time," I'm wondering if it's worth adding the extra query to do this. I can't think of any cons to simply stating it in the description off the top of my head (especially since hard blocking all existing versions is a pretty big action, and not something that I imagine should be easily dismissed)

[diox]

That entire bit about automatically blocking listed & unlisted versions after 90 days and preventing use of these channels is relatively new (was added July 6th while I was out) and wasn't there when I put the ticket in the sprint - given it's a "should have", I would rather do that separately, I'm not sure it's worth the added complexity.

[wagnerand-moz]

The comments on this item, also suggest an unresolved conversation of a) is this correct or b) should a user only be able to select enterprise on first submission (denying any migration of existing)

That's a great question. In a meeting, I had suggested (a) as one option, not necessarily the solution; Also, it was added to the PRD only recently. There are pros and cons for each. For example, (b) would be cleaner, but then we need to figure out how and support developers on migrating from add-on to another in Firefox. However, I am not sure that is an actual concern for add-ons installed through enterprise policies.

I don't have a great answer for you right now and it might make sense to check in with Alan when he's back but I assume the PR is blocked on this question? If you prefer, we could move forward with (a) (because it's stated in the PRD), with the caveat that we might change the approach.

[chrstinalin]

I'll split it out into a separate PR for now.

[wagnerand-moz]

Sgtm

[nothingrandom]

Adding @diox as a reviewer, as this epic has history from before I joined that I want to ensure is covered in the review

[chrstinalin]

Separate (draft, until this one is merged) PR for blocks here: #25186

In the meantime, I've prevented add-ons with existing listed/unlisted from uploading via the enterprise channel (which is also the other option Andreas provided in the PRD, and further discussed here)