Resolves #567

Before the change?

• parallel_requests was explicitly disabled on github.com

After the change?

• parallel_requests is no longer explicitly disabled on github.com

To paraphrase the rationale behind the change

With ~300 repositories, parallel_requests = false terraform plan -parallelism=30 68.65s user 23.16s system 19% cpu 7:46.27 total

With ~300 repositories, parallel_requests = true terraform plan -parallelism=30 44.51s user 14.47s system 105% cpu 55.640 total

With ~300 repositories, parallel_requests = true, lower parallelism terraform plan -parallelism=10 51.69s user 17.67s system 72% cpu 1:35.17 total

A significant reduction in plan time.

Of course, investigating the reason why it was implemented in such a manner, I've come across #145 and the linked official docs that say the following:

To avoid exceeding secondary rate limits, you should make requests serially instead of concurrently. To achieve this, you can implement a queue system for requests.

That being said, given that it makes such a massive difference, and this recommendation is specifically about the REST API (and a bunch of resources now interact with the GraphQL API instead which have more generous secondary rate limits)

Pull request checklist

• Tests for the changes have been added (for bug fixes / features) - N/A
• Docs have been reviewed and added / updated if needed (for bug fixes / features)

Does this introduce a breaking change?

Please see our docs on breaking changes to help!

• Yes
• No