Update backfill guidance for "backfill as a ticket"

[calebatwd]

Is your feature request related to a problem? Please describe.
Using backfill by executing match functions doesn't scale if the server scale exceeds several thousand. Unless functions are organized and orchestrated to get passed profiles containing several waiting matches at once, this is a difficult problem to solve through the backend.

Describe the solution you'd like
I'd like to see a documented guidance for how a user might achieve backfill through a frontdoor ticket-based approach.

By making backfill a "ticket-based" approach, you gain several improvements.

1. Any match function has the opportunity to understand "existing hosts" as a starting point. Everytime it gets activated, it can query for existing games that match it's criteria... fill the game from the pool of matching tickets... then continue to make new games for the remaining tickets.
2. Backfill tickets can remain "backfilling" for longer. Currently, backfilling servers must constantly request function runs and are regularly synchronized with the director. Missing a sync window means the backfilling host misses out on players in the pool on a regular cadence. This is largely problematic in low population pools where the aggressive timing of the match functions by a director can drain the pool before hosts have a chance to backfill.
3. Backfill tickets can be picked up by several functions... just like with tickets this means they can be considered potential hosts to several several different concerns and needs of the existing match function strategies.

[Laremere]

dup of #1148