Support assigning brokers to multiple BrokerCells

[grantr]

Problem
When Brokers and Triggers are created or updated, assign them to a BrokerCell by annotating the Broker or Trigger object. For the first version this can be a hardcoded cell name.

EDIT(liu-cong@): Instead of annotating, we should label the Broker, so that we can list Brokers for a Brokercell in order to do garbage collection.

Assignment of Triggers is optional. We expect that under normal operation triggers don't need to be assigned because they are associated with an assigned Broker. However, we probably should assign anyway for two reasons:

• so they can still be routed when their Brokers don't exist. This may or may not be a feature we want.
• so it's easier to identify which data plane is servicing them without also looking up the Broker object.

Exit criteria:
All Brokers receive an annotation upon creation assigning them to a BrokerCell.

Time Estimate (optional):
2

Additional context (optional)
A future version of this assignment webhook might use a map of namespaces to BrokerCells to assign instead of assuming a single BrokerCell per cluster.

[grantr]

Let's scope this down to just creating the webhook infrastructure to label broker objects. We can create followup issues to:

• decide and implement an assignment strategy
• use the label in the brokercell controller to select a subset of brokers per brokercell

[grantr]

Instead of annotating, we should label the Broker so that we can list Brokers for a Brokercell in order to do garbage collection.

I'm not sure this is strictly necessary. We can also select brokers using an annotation by looping through the informer cache with no efficiency penalty.

[github-actions]

This issue is stale because it has been open for 90 days with no
activity. It will automatically close after 30 more days of
inactivity. Reopen the issue with /reopen. Mark the issue as
fresh by adding the comment /remove-lifecycle stale.

[github-actions]

This issue is stale because it has been open for 90 days with no
activity. It will automatically close after 30 more days of
inactivity. Reopen the issue with /reopen. Mark the issue as
fresh by adding the comment /remove-lifecycle stale.