Use futures list internally to manage send events

[eliasyishak]

Related to issue:

• Implement futures list internal to analytics instance #183

This PR is adding an internal instance member _futures, which is a list of Future objects that are returned from the http client.

When the user of this package invokes analytics.send(...), they will no longer have to await the call which can delay them. However, at the end, the user of this package should call analytics.close() and await that call on exit to ensure events have been sent.

---

• I’ve reviewed the contributor guide and applied the relevant portions to this PR.

Contribution guidelines:

• See our contributor guide for general expectations for PRs.
• Larger or significant changes should be discussed in an issue before creating a PR.
• Contributions to our repos should follow the Dart style guide and use dart format.
• Most changes should add an entry to the changelog and may need to rev the pubspec package version.
• Changes to packages require corresponding tests.

Note that many Dart repos have a weekly cadence for reviewing PRs - please allow for some latency before initial review feedback.

[christopherfujino]

were we calling analytics.close() on the tool anyway?

I'm thinking (provided other clients aren't implementing this interface), an easier, non-breaking change to make would be to not change the signature of any existing methods, and just adding a new method, waitForLastPing({Duration? timeout}) that clients can choose to opt in to, if they want to ensure an event was sent, or ignore if they'd rather prioritize exiting as soon as possible.

[eliasyishak]

were we calling analytics.close() on the tool anyway?

No, and we didn't really have to because we weren't sending events yet, but that is a good catch for the open PR for me to add in the close statement on exit.

non-breaking change to make would be to not change the signature of any existing methods

And i think this entire PR would be a breaking change regardless since the send methods return type has now changed

[christopherfujino]

I'm saying if we DON'T change the return signature of any existing methods, it won't be a breaking change.

[eliasyishak]

Oh I see, you don't agree on having the send method return void makes sense now though? I understand it is a breaking change but I think this gets us more in line with the legacy analytics

[christopherfujino]

I'm not saying it doesn't make sense, I'm just pointing out the minimal amount of engineering effort would likely be to avoid breaking other clients. If think it's reasonable to force existing clients to migrate, then I'm ok with a breaking change.

[andrewkolos]

LGTM