[WIP]feature: Create hyperNode cr by node label

[JesseStutler]

feature: #3888

The hypernode controller will list/watch node(only node with label volcano.sh/hypernodes will be list/watched) and hypernode, the format of label volcano.sh/hypernode is "hypernode-0,hypernode-1,...,hypernode-0`, use commas to separate the hypernodes of different layers that the node is connected to, from near to far, the front hypernode means the closer to the node.

Take this picture as an example:

Create Hypernodes Tree

1. The node-0 has the label volcano.sh/hypernodes:"s0,s4,s6", then hypernode controller judge there is no s0,s4,s6 hypernodes created, it will create them sequentially( use hyperNodeAction)
2. The node-1 then has the same label, the hypernode s0 will add the member node-1, there are no operations with s4 and s6.
3. same as the previous...

Update Hypernode Tree

Currently, we only allow node label to change tier 1 hypernode, e.g., node-0's label can only from "s0,s4,s6" to "s1,s4,s6", that is, only allowed to change the node's parent hypernode, we don't allow to change the hypernode tier>1, like from "s0,s4,s6" to "s0,s5,s6". And we don't allow to add more hypernode or delete some hypernodes, like "s0,s4,s6" to "s0,s4" or from "s0,s4,s6" to "s0,s4,s6,s7", it may cause some strange hypernode tree structure, and then causing strange scheduling.

---

Now, I only designed the hypernode controller to have one goroutine to handle the node's events. If there are multiple goroutines processing events at the same time, it may cause multiple create requests of the same hypernode to be issued at the same time. Even if there is only one goroutine processing events, when the hypernode create/update requests is already sent to the api-server, the controller may still not have list/watch add/update/delete hypernode events to the hypernode controller yet, so I added hyperNodesCache. After the hypernode create/update/delete request is sent, the local cache will be updated.After hypernode create/update/delete events arriving, the controller will overwride the hypernode in cache.

[JesseStutler]

Please review it and give me some feedback, thanks! @Monokaix @william-wang @wangyang0616 @penggu

[volcano-sh-bot]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by:
To complete the pull request process, please assign shinytang6
You can assign the PR to them by writing /assign @shinytang6 in a comment when ready.

The full list of commands accepted by this bot can be found here.

Needs approval from an approver in each of these files:

• OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[hwdef]

Wouldn't it be better if label volcano.sh/hypernodes had only one value, so it's even less error prone.
We can design another CRD, such as hyperSwitch
In this case.
The node-0 has the label volcano.sh/hypernodes:"s0"
hyperSwitch-s0 has the label volcano/hyperswitch:"s4"
hyperSwitch-s4 has the label volcano/hyperswitch:"s6"
Or we can design a field for hyperSwitch, such as parent,
hyperSwitch-s0's parent is s4
hyperSwitch-s4's parent is s6

Each key corresponds to a value, which looks clearer. HyperSwitch CRD can also support more scenarios in the future.
For example, when a switch fails, we can quickly take it offline.

[JesseStutler]

Wouldn't it be better if label volcano.sh/hypernodes had only one value, so it's even less error prone. We can design another CRD, such as hyperSwitch In this case. The node-0 has the label volcano.sh/hypernodes:"s0" hyperSwitch-s0 has the label volcano/hyperswitch:"s4" hyperSwitch-s4 has the label volcano/hyperswitch:"s6" Or we can design a field for hyperSwitch, such as parent, hyperSwitch-s0's parent is s4 hyperSwitch-s4's parent is s6

Each key corresponds to a value, which looks clearer. HyperSwitch CRD can also support more scenarios in the future. For example, when a switch fails, we can quickly take it offline.

Add a CRD will become more complicated, after discussing with @Monokaix @penggu, we decide to redesign this label later, in this version of network topology, this PR may not be get merged.

[volcano-sh-bot]

@JesseStutler: PR needs rebase.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.