Fix deprecation warning

[andypbarrett]

Description

closes #1301

Extracts code from results.DataGranules.size to a private property results.DataGranules._size.
Deprecation warning is only in results.DataGranules.size so only appears when .size() is called directly.
results.DataGranules.size then calls results.DataGranules._size
Internal calls to get granule size are changed to call results.DataGranules._size

These were in:

earthaccess/formatters.py:    granule_size = round(granule.size(), 2)
earthaccess/results.py:            "As of version 1.0, `DataGranule.size` will be accessed as an "
earthaccess/results.py:            "attribute; e.g. use `DataCollection.size` **not** "
earthaccess/results.py:            "`DataCollection.size()`",
earthaccess/store.py:        total_size = round(sum([granule.size() for granule in granules]) / 1024, 2)
earthaccess/store.py:        total_size = round(sum(granule.size() for granule in granules) / 1024, 2)

Merge checklist

• PR title is descriptive
• PR body contains links to related and resolved issues (e.g. closes #1)
• If needed, CHANGELOG.md updated
• [-] If needed, docs and/or README.md updated
• [?] If needed, unit tests added (unsure how? see below!)
• All checks passing (tip: comment pre-commit.ci autofix if pre-commit is failing)
• At least one approval

---

📚 Documentation preview 📚: https://earthaccess--1420.org.readthedocs.build/en/1420/

[github-actions]

👈 Launch a binder notebook on this branch for commit 39e9e9d

I will automatically update this comment whenever this PR is modified

👈 Launch a binder notebook on this branch for commit e52b7c8

[mfisher87]

How do y'all feel about actually making the breaking change now? We need to do it before v1.0.0 anyway.

[andypbarrett]

That is true. I am happy to rip the bandaid off.

[mfisher87]

I vote in favor of ripping off the band-aid :)

And burning it

🔥 🩹 🔥

[asteiker]

@mfisher87 Can you remind me what making the breaking change means in terms of a new or existing PR? I have lost sight of whether this is already in work or not. Should we still merge this now? I saw this reviewer comment on our PyOpenSci submission and noted that this may be continuing to have some negative user impact.

[mfisher87]

I'm not sure I follow your question. We could do the breaking change in this PR as a means of "fixing" the deprecation warning, and that's what I'm proposing.

I have lost sight of whether this is already in work or not

I believe it is not. The change is very simple so I think there was no incentive to get started on it ahead of time.

I saw this reviewer comment on our PyOpenSci submission and noted that this may be continuing to have some negative user impact.

There are two problems: 1) We have a deprecation warning that gets printed regardless of whether the user calls the deprecated method, because we use the deprecated method internally, and we shouldn't do that. The original intent of this PR is to fix this. 2) Actually replacing the deprecated method (#1421) is a breaking change, and because of the way Python is designed, we can't reasonably have both the deprecated method and the new method exist at the same time (i.e. we can't have a transition period).

We could fix (1) alone and deal with (2) later but I'd instead advocate to take the hit and deal with (2) now. We've had this spammy deprecation warning in the latest version for some time now, folks have seen it. The breaking change is fairly trivial to resolve (users will have to change granule.size() to granule.size in their code). I think there's minimal/no benefit to waiting longer. We should just be noisy about the breaking change.

[andypbarrett]

The @property decorator was added in #1187