Consider storing vignette input data in package

[brookslogan]

@dajmcdon raised the possibility of replacing API queries in the vignettes and examples to internal data, in order to speed up vignette building and help with CI; the fetching code could be left in with an eval=FALSE. The drawback is potential license-related questions: what LICENSE do we assign the package if it mixes MIT-licensed code and CC/other-licensed data?

[brookslogan]

Another factor to consider here: repository and package size. We shouldn't store massive data objects here, to keep git operations responsive and fully-featureful (merge operations can degrade in the presence of massive data objects), and to keep clones and installs quick. (Already the repository is 35MB, not instant to clone.)

[dajmcdon]

I suspect that must be largely the docs/ right? I'm going to try in #71 to move that all to it's own branch. Though that won't help unless you do a shallow clone. Typical remotes::install_github() behaviour seems to be to actually download the repo (rather than clone), so this could be a problem.

All that said, I'm going to try to enforce the "no data bigger than 1MB" rule.

[brookslogan]

I would also guess that's the case. With the current main checked out, docs looks like it's 97.5% of the checked-out content.

I'm just skimming here [... I guess that was the wrong place, maybe here is more relevant, but it looks like remote_download.github_remote still attaches the ref so maybe the conclusion is the same?] and to me it looks like it should just download a HEAD snapshot from the GitHub API, so I would think that moving docs/ to its own branch would avoid slowdowns for remotes::install_github() (and maybe also merge slowness, but large default clones would remain a potential issue).

[brookslogan]

I think we may need to keep some of the docs for basic help to work with install_github. Looks like 96% of the current (checked out snapshot) docs space is from pngs for the articles.