fix(fcm): Exposed admin.messaging namespace

[hiranya911]

• Defined messaging API signatures in messaging/index.ts.
• Exposed admin.messaging namespace.
• Exposed App.messaging() method.

Notable changes/fixes

Following incompatibilities/errors were discovered and fixed.

FirebaseError.stack property

The above property had been defined as required. However, core typings for Node.js defines stack to be an optional property.

interface Error {
    stack?: string;
}

This caused a compilation error when I implemented our FirebaseError interface in the FirebaseError class. I treated this as a bug in the existing typings, and fixed it by making the stack property optional.

Legacy FCM APIs

We have following 2 methods in the typings:

// messaing/index.ts
sendToDevice(
      registrationToken: string | string[],
      payload: MessagingPayload,
      options?: MessagingOptions
): Promise<MessagingDevicesResponse>;

sendToDeviceGroup(
      notificationKey: string,
      payload: MessagingPayload,
      options?: MessagingOptions
): Promise<MessagingDeviceGroupResponse>;

But the implementation had them declared as follows with union return types.

// messaging/messaging.ts
sendToDevice(
      registrationToken: string | string[],
      payload: MessagingPayload,
      options?: MessagingOptions
): Promise<MessagingDevicesResponse | MessagingDeviceGroupResponse>;

sendToDeviceGroup(
      notificationKey: string,
      payload: MessagingPayload,
      options?: MessagingOptions
): Promise<MessagingDeviceGroupResponse | MessagingDevicesResponse>;

It seems the implementation does actually return a union type too. I thought about considering this as another bug in the existing typings (it really is), but ultimately didn't want to expose union return types from a public API. A method that has multiple return types is really awkward to use in practice. So instead, I kept the public API signature as is, and changed the implementation to adhere to the existing typings. I did so in a backward compatible way so that developers who are relying on the current implementation behavior won't break.

[lahirumaramba]

LGTM! Thank you!