[Multitenancy]: Add PodNetwork CRD

[aggarwal0009]

Reason for Change:

This CRD is added to enable VNET multitenancy – which will be watched and managed by the control plane.
These represent a Cx subnet already delegated by the customer to the Orchestrator RP

Issue Fixed:

Requirements:

• uses conventional commit messages
• includes documentation
• adds unit tests
• relevant PR labels added

Notes:

[neaggarwMS]

I would call the whole Subnet ResourceId here.

[aggarwal0009]

So should I rename it SubnetID? SubnetResourceID?

[thatmattlong]

@neaggarwMS would subnet resource id have vnet guid? If so, maybe we can drop vnetGUID and just have subnet resource id

[thatmattlong]

nevermind, it would not have vnet guid, confirmed it with vipin

[aggarwal0009]

Updated to SubnetResourceID

[neaggarwMS]

For Azure Naming, lets call it VnetGuid.

[aggarwal0009]

updated

[thatmattlong]

Do we need a Nil status? Conceptually, what is the difference between "Nil" and ""?

[miguelgoms]

no, we don't need nil as an enum value.

[aggarwal0009]

removed

[thatmattlong]

I thought we were going to use events on the object to convey error messages instead of putting it into the object. It's kind of an anti-pattern to have a field for error message in a resource (can't think of any other k8s resource that has a field like this)

[miguelgoms]

I think we agreed to use enum values on status for known error categories => actionable repair item. (e.g.: subnet is not delegated to this service => revalidate and create the SAL)

For error debug details we discussed having the error message, but agreed that can just go into events if the status enum is informative enough.

[aggarwal0009]

removed errorMessage field in favor or events.

[rbtr]

couple nits, otherwise lgtm