Optimizer registration ordering is error prone #3131

Problem Statement

When registering new query planner optimizers, you currently provide a priority as a number; this number resolves the order in which the optimizers run.

As the number of optimizers grow, it becomes very difficult to compute the total ordering of the registered optimizers or make changes to their order.

This issue was first raised here: #3051 (comment)

Solution Brainstorm

There are a variety of solutions that could help here with various trade-offs:

• Developer tooling to compute and print the optimizer orderings
• Consolidate registration into one place where the code reads as ordered list, similar to registering gRPC middleware
• Replace priority number with "before" and "after" fields that resolve order similar to systemd unit files or our existing db migration tooling