feat: Add Firestore module

[dejandjenic]

What does this PR do?

Why is it important?

Related issues

[netlify]

✅ Deploy Preview for testcontainers-dotnet ready!

Name	Link
🔨 Latest commit	10ee846
🔍 Latest deploy log	https://app.netlify.com/sites/testcontainers-dotnet/deploys/6506a6db5915190008bbe5e3
😎 Deploy Preview	https://deploy-preview-988--testcontainers-dotnet.netlify.app/modules
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify site configuration.

[HofmeisterAn]

Thank you for your pull request. I have some requests. As soon as they are addressed, we can merge the module. Thanks.

[dejandjenic]

i pushed new changes to resolve comments made to PR, i didn't resolve comments themselves unsure what are practices here. if required i can do that.

[HofmeisterAn]

Thank you for updating the pull request and addressing the requests. I made some minor adjustments, nothing significant. The pull request looks good 👍.

One thing I'd like to discuss is whether it makes sense to rename the module to "GCloud," similar to Java. This change would allow us to provide different container implementations, much like what Java does here. Additionally, should we renaming the container to FirestoreEmulatorContainer? This PR is related to #862 too.

[dejandjenic]

I can do a push with renaming tommorow, gcloud naming is similar to java containers but dotnet containers have different setup. E. G. Azure is not single module. What ever you decide. I plan to push pubsub in aonther pr also

[HofmeisterAn]

Hmm, I think it depends on how often these containers may be used together and whether they share common configurations. @eddumelendez , based on your experience with Java, do you think it makes sense to publish them as separate modules or within a single one (the GCloud emulators)? Any opinion regarding the name (FirestoreContainer vs. FirestoreEmulatorContainer)?

[dejandjenic]

basically they don't share configuration at all, for usage point it depends on what are you testing
e.g. in my company we use several levels of testing

if containers are used in unit test then responsibility of certain class is unlikely (should not) involve multiple concerns, repository, service ... should work with firestore or pubsub or bigquery ...
if containers are used for functional (integration) testing via testserver then at server setup it might need to setup entire infrastructure which could need setting multiple containers (here module approach would help)

IMHO i would stick to general testcontainers dotnet design which is one container per service, but this is up to you

on naming i would go with FirestoreContainer , we all know it is an emulator :-)

[eddumelendez]

I think it depends on how often these containers may be used together and whether they share common configurations.

Testcontainers modules based on google-cloud-cli image don't share any config. They are group based on the concept of the GCP services.

The relationship between modules and implementation shouldn't be always 1:1. In the future, a confluentic module can be shared providing Testcontainers implementations for schema registry, kafka, ksqldb and others. The same for percona database which offers images for mysql, postgres

Feedback about this topic is welcome.

Any opinion regarding the name (FirestoreContainer vs. FirestoreEmulatorContainer)?

FirestoreContainer is ok 👍🏽