Asset Size Check Improvements

[runspired]

The AssetSizeCheck that runs on PRs could be improved in the following ways, listed below in the order of priority

• [x] We should update the comment in place instead of deleting it and posting a new one
• [ ] bot to post and manage the results comment since PRs from forks don't have permissions
• [ ] ability for data core team members to approve an asset size increase via a comment ala @github-action AssetSizeIncreaseOK <some description of why> which will cause CI to pass for the increase while still reporting it.
• [ ] either manually specify a list or diff the output of ember new to get a list of all files added to app/ by ember-data so that we can correctly track them as part of our footprint
• [x] add parallel tracking of our size when not supporting IE11
• [ ] upload to S3 or similar a per-commit-to-master history of our asset size for tracking
• [ ] app to view asset size history over time

Minimum Data Check

• [ ] a "minimum possible ember-data" app (similar to the encapsulation test apps) that lets us track the smallest ember-data implementation with the rough basics of management for network, cache, presentation, and mutation

Because we conditionally remove code that exists to support specific legacy packages (notably model/adapter/serializer) the reported size of store which represents the essential core of ember-data is over-reported. As we work to rationalize the network layer this over-reporting will become even more substantial. It is already likely close to 30% of the reported size of store, and as we continue to deprecate the legacy model world it's likely this number grows as high as 70%.

We should build a tiny package that just installs the store package (the only essential package at this point) and reports it's size. Since most folks will likely choose to use our cache as well we should probably build a similar scenario for those two packages.

Improved Accounting

• [ ] the asset-size check occasionally displays wrong math
• [ ] adjust the mechanism of the check to account for v2-addon builds

An example of this is in https://github.com/emberjs/data/pull/8078 where a reduction of about 3.5kb compressed is correct in the total but displays as 75kb in the relative change.

Related #8086 #8103

[runspired]

Related: https://github.com/emberjs/data/issues/6678

[runspired]

Now that our existing infra has had time to mature we've come up with a few tweaks to improving it:

1 - we need a bot to post and manage the results comment since PRs from forks don't have permissions 2- We should update the comment in place instead of deleting it and posting a new one