Retrieves Firebase Project ID from the provided service credential file

[xavarius]

This fixes #142
The pull request adds automatic Firebase Project ID handling by retrieving it from the provided configuration/credential file.
Since the service credential file (exported from the Firebase) contains this project ID, the PR removes duplication in the client initialization.

I would suggest releasing new version with this change, possibly major one, since it's a breaking change.

PS
I have not found any confirmed Firebase service credentials json schema, which kinda makes sense to not disclosure it, but we're all working here with assumptions around the API and file schema.

[xavarius]

@sabman @kashif Could I ask you to review the PR and discuss if needed? :)

[xavarius]

@sabman @kashif Would you be open to including this improvement? Let me know, please. If not, I would consider useing my fork in the project to simplify this bit. :)

[xavarius]

Dear @sabman, I'm fully aware you may need some time to review this. Could you please let me know if you would have opportunity to do it like this month? :)

Thanks a lot!

[sabman]

@xavarius can you please reference the file schema in the code? Sorry for the delay on this.

[sabman]

Also maybe we wanna do it as a non-breaking change with a deprecation warning?

[xavarius]

@xavarius can you please reference the file schema in the code? Sorry for the delay on this.

No worries. Excuse me. But What do you mean by referencing file schema in the code?

[xavarius]

@sabman hello there, I applied both improvements and merged what was already in the origin/master branch.

Could we proceed with it? Lemme know. :)

[sabman]

We could I'm keen to hear from others about backwards compatibility given it's a breaking change. Also security perspective it would be great to confirm if google provides a schema even if undocumented?

[xavarius]

@sabman I implemented it in the way that is it not a breaking change anymore, as asked. Covered by units of course.

Yeah, the undocumented schema is tricky. I wasn't able to find the documentation, as shared in the PR description.
So the question is: Are we ok with this assumption around the schema?

My thoughts are:
The schema change would be super impactful, so not only for this lib, but all (most at least) clients, libs and consumers. All of those would be affected by any random schema changes. Thus, the assumption around the schema seems to be OK, at least to me. It's your call in the end, of course - I want to help a bit, I do not want to force something that community is not comfortable with.