Add App-scoped API For Firebase Project management

[xiangkangjw]

App-scoped actions for Firebase apps within Firebase projects. Uses Firebase Management REST APIs (https://firebase.google.com/docs/projects/api/reference/rest/)

[schmidt-sebastian]

This PR only contains previously reviewed changes.

[weixifan]

I fixed some iOS vs Android mistakes in the Javadoc for various methods in FirebaseProjectManagement. I will assign a reviewer in case there are comments about that change.

[weixifan]

I also just adjusted the error codes list. Both Android certificates and Apps are handled by the same error codes map, so I changed the term "App" to simply "resource." Please take a look.

[schmidt-sebastian]

Still LGTM

[weixifan]

Unfortunately I discovered more things to fix. :(

[hiranya911]

Thanks for putting this together, and sorry for not commenting on it earlier. Please check out the things I've pointed out.

[weixifan]

These should be public. Please see the API proposal document for the precise public API.

[hiranya911]

Thank you for making the changes. I think we're almost there. My big concern is around how the waiting/polling logic is implemented. I would advocate for a simpler implementation using loops and Thread.sleep(). Then just run the logic on the calling thread (for sync methods), or on a separate thread (for async methods). Take everything else as an optional suggestion.

[hiranya911]

Please expose the existing FirebaseApp.schedule() method via a trampoline. Also look into implementing this waiting logic as a simple loop with Thread.sleep() without using additional threads (see my comments below). Then we can treat this method as any other method in the SDK, and have it be called either on the calling thread (for sync operation) or a separate thread (for async operation).

[weixifan]

Edit: The question below has been resolved. Just confirmed with my teammate that we are deliberately enforcing the rule that any ShaCertificate that the user wants to delete must come from the getShaCertificates(...) call. We will keep the other constructor package private. Thanks.

Thanks for the review. Aside from the asynchronous polling question that remains, we have another small issue: I noticed that for the AndroidApp.deleteShaCertificate(...) method, the caller must pass in a ShaCertificate, constructed with the name field set. This means we either force the caller to only be able to pass in a ShaCertificate returned by the getShaCertificates() method, or we expose a public method allowing the caller to create a ShaCertificate with a caller-supplied name field. I think we should allow the user to delete Android SHA certificates without having to call getShaCertificates first, if they happen to know the full resource name of the certificate they want to delete prior to calling it, but this isn't that critical. Please let me know what you think.

[hiranya911]

LGTM. Thanks for making the changes.

[weixifan]

Thank you for the reviews. I have added the client version header as we discussed.