refactor: e2e tests using cloud trace v1 api.

[ehsannas]

Add end-to-end tests. Each end-to-end test enables tracing, performs one or more Firestore operations, and then queries the Cloud Trace backend to see if the expected trace and spans have been generated.

[milaGGL]

why the timeout is extended? would this slow the full cycle down?

[ehsannas]

yeah it'll slow down the start-to-finish time of the "integration tests CI". This PR adds 120 tests and the tests take a while because each test does at the very least one round trip to Firestore server, and at least 2-3 round-trips to cloud trace server (because the traces don't become available in the cloud trace server immediately, so we need to retry).

I am open to suggestions about how to reduce this cost. Maybe we should run the in-memory tests on PR CI and cloud-trace backend tests on a nightly basis.

[milaGGL]

if only 10 minutes are added on top to run the whole system test, I think we could live with that comparing to having some part of the code not tested in PRs.

[milaGGL]

it does not allow me to add comment dt non-diff lines, so here is a question:

[ehsannas]

Regarding your question:

For the time being, the reason this interface is here and not in firestore.d.ts is that we don't want to make the API public yet. So there's currently no public API in the Settings interface for setting the otel options. However, Settings can accept any options. So we'll use that for now.

Once we release this feature, we will move the export interface FirestoreOpenTelemetryOptions definition out of here and put it in firestore.d.ts; and we will add a openTelemetryOptions field to the Settings interface.

Java does have FirestoreOpenTelemetryOptions and a way to set it in the FirestoreOptions.

Note that there is an inherent difference between OTEL in java and node.js. In Java the Firestore SDK accepts an instance OpenTelemetry, but in Node.js it's modularized, so we need to accept an instance of a TracerProvider.

[milaGGL]

LGTM