Support for affinity

[Angelin01]

Support for affinity

Add support for affinity injection.

This will include the configuration format for the node selectors.

Out of the three main things we will modify, affinity is probably the hardest to implement as we have nodeAffinity,
podAffinity and podAntiAffinity, all of which our user could configure. Consult the Kubernetes Reference for
more detail.

All the affinity types use node selector terms, either in pure form or array form. As such, we can probably reuse the
validation code for the nodeSelector and toleration features, and they should be implemented earlier.

TODO: List all the possible cases we need to test for.

As a suggestion, we can probably ignore podAffinity and podAntiAffinity for the time being, as the use cases for "making pods in this namespace run in the same/different nodes than these other pods" are waaay less frequent/likely than our simple initial case of "making pods in this namespace run in these nodes".

[Angelin01]

Since affinity is so complex, ideally we either: append to the existing lists, or substitute them. There's no point trying to do any fancy "merges".

The fields we have to watch for are:

• nodeAffinity.requiredDuringSchedulingIgnoredDuringExecution.nodeSelectorTerms
• nodeAffinity.preferredDuringSchedulingIgnoredDuringExecution
• podAffinity.requiredDuringSchedulingIgnoredDuringExecution
• podAffinity.preferredDuringSchedulingIgnoredDuringExecution
• podAntiAffinity.requiredDuringSchedulingIgnoredDuringExecution
• podAntiAffinity.preferredDuringSchedulingIgnoredDuringExecution

[Angelin01]

We'll focus on:

• nodeAffinity.requiredDuringSchedulingIgnoredDuringExecution.nodeSelectorTerms
• nodeAffinity.preferredDuringSchedulingIgnoredDuringExecution

Which can be summarized as nodeAffinity.

There is a use case for podAffinity and podAntiAffinity, but it's much weaker than affinity for this project.