feat(firestore): adds Bulkwriter support to Firestore client

[telpirion]

Adds support for BulkWriter to the Golang client.

• Python impl.
• Java impl.

[enocom]

One last thing about closing the bulk writer.

[gcf-merge-on-green]

Merge-on-green attempted to merge your PR for 6 hours, but it was not mergeable because either one of your required status checks failed, one of your required reviews was not approved, or there is a do not merge label. Learn more about your required status checks here: https://help.github.com/en/github/administering-a-repository/enabling-required-status-checks. You can remove and reapply the label to re-run the bot.

[enocom]

I think there might be a minor race condition here. Here's the idea:

• Goroutine 1 in checkWriteCondition acquires the lock, sees that isOpen is true, and then releases the lock
• Goroutine 2 in End acquires the lock, sets isOpen to false, releases the lock, and then flushes
• Goroutine 1 meanwhile starts a write

The question is: does the write succeed or not in this case?

One possible option would be to use a read write mutex, where the read mutex wraps the entire write attempt and the write mutex wraps isOpen here in End.

[telpirion]

Very good point.

Here's what I've done to address this:

• Changed BulkWriter.isOpenLock to a RWMutex.
• Added a Lock() and deferred Unlock() at the top of each DB mutator/write function (Create(), Delete(), etc).

Each mutator will hold the lock while queueing up the write for the Bundler. If End() is called during this time, it will will block while the mutator holds the lock.