Merge fields instead of overwriting whole doc

[yuvalkarmi]

I've discovered that the updateUser method of the adapter in Firestore overwrites the record if it already exists. This results in user information being lost upon update. For example, when logging in with the email provider.

Right now the bug is this:

1. User collection has the following record:

{
      id: '12345'
      emailVerified: <some timestamp>
      email: 'jsmith@example.com'
      image: <some image>
      name: 'John Smith'
}

2. User logs in with email, and as a consequence, next-auth calls the updateUser method of the adapter with the data:

{
      id: '12345'
      emailVerified: <some NEWER timestamp>
}

3. Record gets overwritten completely and is now:

{
      id: '12345'
      emailVerified: <some NEWER timestamp>
}

This pull request sets the merge flag on the firebase set command to true so that the record isn't overwritten.

However, this isn't enough, because next-auth expects to receive the updated record including the original fields, which means we need to somehow get the original fields (otherwise, the session won't include the user's profile).

Unfortunately, the firebase javascript SDK (unlike the REST API) does not return the updated record in response to set or create calls (see here). As a consequence, we must make an additional call to retrieve the updated record, and then return that to next-auth.

This pull request takes care of both of these changes. Please keep in mind that I have not updated any other methods or anything outside of the firestore database (if the firebase file needs to be updated as well, this should be done, too. However, I am unfamiliar with it).

[fronterior]

First of all, thank you for writing the PR.

Could you write in detail how to reproduce the problem?

In my test, the data was not erased when I entered a new field in the user of Firestore in the current version, logged out, and logged in again.

For your information, there is a conflict because there is a mistake in the current version update, and this will be resolved manually, so please don't worry.

[fronterior]

The *.js file is the result of the build. So it's right to be included in the .gitignore list. So I think all the changes to this commit are inappropriate.
I used the method of building in the root folder for the purpose of using alias when distributing to npm, but I will modify it to distribute by folder using tools like chakra-ui later.

mistake