Document Spread scheduling algorithm

[schmichael]

Cluster-wide spread scheduling was added in #7810 but is only briefly referenced in API docs.

We should ensure it's documented in relevant places as well as explain when it should be used. Some ideas:

[ ] Internals: Scheduling

https://www.nomadproject.io/docs/internals/scheduling/

This page is a brief overview, and a 2-3 sentence description of the 2 cluster scheduling algorithms may be appropriate/useful:

As of Nomad v0.11.2 two cluster scheduling algorithms are supported: binpack and spread. The default is binpack and minimizes the number of servers needed to run services. The spread algorithm evenly places services across all servers and is best for static clusters, such as on-premises bare metal. See Scheduling Internals or the Scheduler Configuration API for details.

[ ] Internals: Scheduling: Internals

(Wow we need to update our information infrastructure too, huh?)

This is going to take more work than above to update as there's not a clear place to drop in a mention of spread. Probably split up this paragraph or add a new paragraph after:

The second phase is ranking, where the scheduler scores feasible nodes to find the best fit. Scoring is primarily based on bin packing...

[ ] Installing Nomad: Production: Reference Architecture

Should mention spread somewhere near "bare metal." A new section might be appropriate.

[x] API: Operator - Complete in #7994

This could be its own ticket, but we should really link to the Scheduler Defaults page from the Scheduler Config API.

Probably even be a little prescriptive and suggest people try to bake the desired scheduling configuration into their Nomad server images to avoid runtime configuration mutability.

[angrycub]

@schmichael, @shantanugadgil started a PR for the scheduler defaults page (#7994), and we have been talking over part 3 (API: Operator). It seems like the API page is the canonical documentation from a long-term usability perspective. (also not having to document the defaults in a place far removed from the API that becomes authoritative immediately after bootstrapping). I'm sure we could add an interlinkage to the default_scheduler_config setting from the API docs page tho.