fix(database): refactor "removeObserver" to fix memory leak

[ened]

Description

Similar to #261, this PR removes a memory leak when a App is analyzed using the LeakCanary plugin.

The Android lifecycle is very strict when the "Don't Keep Activities" developer setting is turned on. In that case, only the native side of the plugin will get a callback to release the resources. This has been partially mentioned in flutter/flutter#32948.

Checklist

Before you create this PR confirm that it meets all requirements listed below by checking the relevant checkboxes ([x]). This will ensure a smooth and quick review process.

• I read the Contributor Guide and followed the process outlined there for submitting PRs.
• If the pull request affects only one plugin, the PR title starts with the name of the plugin in brackets (e.g. [cloud_firestore])
• My PR includes unit or integration tests for all changed/updated/fixed behaviors (See Contributor Guide).
• All existing and new tests are passing.
• I updated/added relevant documentation (doc comments with ///).
• The analyzer (flutter analyze) does not report any problems on my PR.
• I read and followed the Flutter Style Guide.
• I updated pubspec.yaml with an appropriate new version according to the pub versioning philosophy.
• I updated CHANGELOG.md to add a description of the change.
• I signed the CLA.
• I am willing to follow-up on review comments in a timely manner.

Breaking Change

Does your PR require plugin users to manually update their apps to accommodate your change?

• Yes, this is a breaking change (please indicate a breaking change in CHANGELOG.md and increment major revision).
• No, this is not a breaking change.

[ened]

@invertase This PR, along with a followup for a similar implementation on cloud_firestore would be a suggestion.

[ened]

@kroikie, @ditman after #2733 , perhaps you are interested in the same thing, but for the database component? :-)

[kroikie]

Thanks @ened I'll take a look.

[ened]

@kroikie do you have any update or thoughts on this?

[ened]

@Ehesp - FYI - guess this becomes obselete once the rework is ready?

[Salakar]

@ened is this PR still valid, if so I'd like to get it reviewed and shipped - let me know, thanks :)

[ened]

@Salakar still relevant, yes.
This has been tested manually, only.
A good goal in the future could be integration of https://square.github.io/leakcanary/recipes/#running-leakcanary-in-instrumentation-tests into instrumentation/driver tests.

[Salakar]

LGTM, thank you again for another PR :)

[Salakar]

A good goal in the future could be integration of square.github.io/leakcanary/recipes/#running-leakcanary-in-instrumentation-tests into instrumentation/driver tests.

Agree, we're still tweaking the new CI setup on GitHub actions but I think once we're comfortable everything is running smoothly, de-flaked and stable we can start introducing new checks like this and other things like pod lint and Android lint build checks too.