Check permissions on feature initialization

[Elgarni]

Description

This PR is a follow-up on #1669, that when merged should fix permissions issues such as #1668.

Checks were added prior to initializing a feature, such that if the user lacks a permission, they are told so, and the initialization is aborted.

Scenarios Tested

Scenario: The user tries to initialize a firebase feature, with a Viewer role on an existing project called example-project

Before this PR, the output will be similar to this issue #1668.

After this PR, the output on each feature will be as follows:

• init Database

=== Database Setup

Error: Authorization failed. This account is missing the following required permissions on project example-project:

  firebasedatabase.instances.update

• init Firestore

=== Firestore Setup

Error: Authorization failed. This account is missing the following required permissions on project example-project:

  datastore.indexes.create
  datastore.indexes.delete
  datastore.indexes.update

• init Functions

=== Functions Setup

Error: Authorization failed. This account is missing the following required permissions on project example-project:

  cloudfunctions.functions.create
  cloudfunctions.functions.delete
  cloudfunctions.functions.update

• init Hosting

=== Hosting Setup

Error: Authorization failed. This account is missing the following required permissions on project example-project:

  firebasehosting.sites.update

• init Storage

=== Storage Setup

Error: Authorization failed. This account is missing the following required permissions on project example-project:

  firebaserules.releases.create
  firebaserules.releases.update
  firebaserules.rulesets.create

---

Let's discuss if there are potential issues with these new checks.

[coveralls]

Coverage decreased (-0.04%) to 65.177% when pulling 1b20ff2 on Elgarni:check-permissions-on-feature-init into c9019ff on firebase:master.

[Elgarni]

@bkendall Any update on this?

[bkendall]

Yes, I have an update.

Thanks for the PR and all the work getting to this point. However, after talking it over with a couple folks, this is not the behavior we want init to have. While a user may not have permissions to do something in a project, we don't want to gate init of any feature on that as a requirement. When the users takes an action that requires those permissions, we want to make sure we provide a useful error message at that time to help them get unblocked and moving forward.

Thank you for the effort, but we won't be moving forward with this PR.

[Elgarni]

Sure no worries.

Just gave the CLI a try with your PR#1790 changes, and had the same output as in this PR. It's a good thing that we agree on what to show to the user in this case :)