Add null to databaseAuthVariableOverride

[MathBunny]

I noticed that the databaseAuthVariableOverride does not accept null in the source:

firebase-admin-node/src/firebase-app.ts

Lines 48 to 56 in 488f931

	export interface FirebaseAppOptions {
	credential?: Credential;
	databaseAuthVariableOverride?: object;
	databaseURL?: string;
	serviceAccountId?: string;
	storageBucket?: string;
	projectId?: string;
	httpAgent?: Agent;
	}

Meanwhile, in typings it accepts null:

firebase-admin-node/src/index.d.ts

Lines 138 to 163 in 488f931

	credential?: admin.credential.Credential;
	/**
	* The object to use as the [`auth`](/docs/reference/security/database/#auth)
	* variable in your Realtime Database Rules when the Admin SDK reads from or
	* writes to the Realtime Database. This allows you to downscope the Admin SDK
	* from its default full read and write privileges.
	*
	* You can pass `null` to act as an unauthenticated client.
	*
	* See
	* [Authenticate with limited privileges](/docs/database/admin/start#authenticate-with-limited-privileges)
	* for detailed documentation and code samples.
	*/
	databaseAuthVariableOverride?: Object | null;
	/**
	* The URL of the Realtime Database from which to read and write data.
	*/
	databaseURL?: string;
	/**
	* The ID of the service account to be used for signing custom tokens. This
	* can be found in the `client_email` field of a service account JSON file.
	*/
	serviceAccountId?: string;

Another observation is object vs Object discrepancy, from my understanding object is generally preferred but I don't know if it's safe or worth changing the typings for this.

[lahirumaramba]

It makes sense to me. I am adding @rsgowman for his input as the null checks were added as part of #676

I think you are right. We probably should use object instead of Object. I see multiple places where we have used Object in code :)
https://www.typescriptlang.org/docs/handbook/declaration-files/do-s-and-don-ts.html

[rsgowman]

This looks right to me; I'm sure I just missed adding the | null when I did that earlier PR. (Thanks!)

Re Object vs object: I also agree that we should be using object. It's a real easy mistake to make; I certainly didn't notice the discrepancy when working on #676 and it's a safe bet that the original author (and reviewer) didn't intend for this difference either.

I don't know the implications re api change though. It's worth running that by Hiranya. Either way, I'd lean towards submitting this as is and doing a separate PR for the s/Object/object change. (Lahiru, I'll let you and Hiranya work out the best path forward for that.)

[lahirumaramba]

Thank you, @rsgowman !

[lahirumaramba]

Thank you @MathBunny! LGTM!

[hiranya911]

@schmidt-sebastian can you also take a quick look?

[hiranya911]

LGTM

[schmidt-sebastian]

LGTM based on https://github.com/firebase/firebase-js-sdk/blob/65c05e2c698ab138a98533deab8fe7ad4732a303/packages/database/src/core/Repo.ts#L104

[MathBunny]

Thanks @schmidt-sebastian - will merge this now and then will discuss with Hiranya and Lahiru next steps for the Object vs object discrepancy in another PR.