evaluate enabling git lfs on this repo

starting a discussion here as I think there's a warning from the weekly generation logs we've probably missed over time as the OpenAPI descriptions grew.

remote: warning: See http://git.io/iEPt8g for more information.
remote: warning: File openapi/beta/openapi.yaml is 50.57 MB; this is larger than GitHub's recommended maximum file size of 50.00 MB
remote: warning: GH001: Large files detected. You may want to try Git Large File Storage - https://git-lfs.github.com.

(when pushing OpenAPI descriptions)

Currently the metadata clone of the repo takes about 8 seconds on the weekly generation process. This is not a big deal big any measure. However I suspect that clone/fetch operations are much slower on slower connections. I'm personally alone on a dedicated fiber connection, but I recognize this is not the case for everyone.

some early LFS users report a 10X improvement (note: no need to use a separate command anymore, it's just the regular git clone command).

I don't think we should optimize something if it's not a problem, but I wanted to double check whether it is a problem or not for people who often work on this repo?

(interestingly native GitHub features like contributors or commits under insight never return, and I suspect it's related)

CC @zengin @peombwa @MIchaelMainer @irvinesunday

Start with the weekly generation logs and openapi/beta/openapi.yaml, then review the repository's clone and fetch behavior around the reported GitHub large-file warning. Done means reaching and documenting a decision on whether enabling Git LFS is warranted; the issue does not identify tests or a specific implementation entry point.