Add support for firestore

[falk-stefan]

Is your feature request related to a problem? Please describe.

I would like to store jobs using firestore.

Describe the solution you'd like

Similar to the MongoDBDataStore there should (or could) be a FirestoreStore.

Describe alternatives you've considered

Not sure if there is another alternative in this case.

Are you willing to contribute

Depends if apscheduler wants to add support for the firestore. Should one of the main contributer offer implement this, it would probably be faster. If nobody is willing to do it, I can imagine creating a PR mainly because I'd like to use this library in combination with firestore myself.

Required changes (TODOs)

I gave this some thought. In theory, this should not be very complicated. One could probably take the MongoDBDataStore as a template for this. The "complicated" part, I presume, will be testing it. It's possible to utilize the emulatore provided by firestore for this.

General:

• [ ] Add firestore.py module to apscheduler.datastores and implement FirestoreStore
• [ ] Add a new firestore_store as @pytest.fixture in test_datastore.py
• [ ] Add firebase_admin >= 5.2.0 as dependency to setup.cfg

GitHub workflows:

In preparation for unit tests:

• [ ] Install npm actions/setup-node@v2
• [ ] Install firebase tools npm install -g firebase-tools
• [ ] Run the emulator firebase emulators:start --only firestore
• [ ] Create credentials file (if not available in the git-repository)** for the firestore client

** firebase_admin requires some (fake) credentials to connect to the emulator. One could A) simply add a credentials.json to the (git) repository or B) create that file within the github workflow.

[agronholm]

I have my hands full with v4.0 development, and my other FOSS projects. It might be best to provide this as an external add-on.

[falk-stefan]

@agronholm I can't promise anything, but what if I provided a PR?

[agronholm]

I am reluctant to accept such a PR because it would add to my already heavy maintenance burden. Only if this becomes popular enough to justify being added to the main codebase, would I consider it.

[agronholm]

Closing as not planned. It's not a bad idea per se, but would require a PR to even consider.