Remove fields, RAW Capacity, Burst

[jggoebel]

What this PR does / why we need it:

Which issue(s) this PR fixes:

Remove IDs / other unused components
fixes hobbyfarm/hobbyfarm#246
fixes hobbyfarm/hobbyfarm#245
fixes hobbyfarm/hobbyfarm#244
fixes hobbyfarm/hobbyfarm#243
fixes hobbyfarm/hobbyfarm#254
fixes hobbyfarm/hobbyfarm#255

Remove Burst Count & Raw Mode
fixes hobbyfarm/hobbyfarm#237
fixes hobbyfarm/hobbyfarm#236

Environment Modal
fixes hobbyfarm/hobbyfarm#234

Supporting multiple environments
fixes hobbyfarm/hobbyfarm#161

[jggoebel]

10c5189 also changed how calculation of available VMs for a given period works.

First of all this is needed to display available VM Counts in the Admin-UI per Environment and Period (Start and End of Event) when creating or updating ScheduledEvents.

Before this change multiple datapoints between start and end were calculated (for every 30 minutes). We then checked every scheduledEvent for every of this timestamps (672 for a 2-Week Event) and calculated if the event is happening at this datapoint. We then added up the virtualmachines from all events for this single datapoint.
When all datapoints were calculated we once again went through all datapoints and figured out the maximum.
So for a 2 Week Event and 10 Events running we ran 7392 (672 * 10 + 672) times through loops. This was O(m*n) where m is the duration of the event and n the number of events.

I changed this behaviour to calculate only on timestamps where a change in virtualmachine counts is happening (Start or End of any Scheduled Event). So if we have 10 ScheduledEvents we would have 20 Timestamps to calculate on. Also we can simply add up VirtualMachine Counts for every of these datapoints and do not have to iterate once again to figure out the maximum.
For the same 2 Week Event and 10 running Events we now have 20 iterations. And we do not scale by event duration anymore. Longer Event does not require longer calculation (Maybe if we have more events that are in this timerange though). This is O(2n)

[jggoebel]

Count capacity can now also be set via Admin-UI

[jggoebel]

Progress CRDs are now kept until the event is deleted to tretreive more stats after the event is finished

[jggoebel]

Also removing left overs from #85

• Remove DynamicBindRequest as it is unused

[jggoebel]

Last commit implements vmclaimcontroller to respect Count Limits from environments and scheduledEvents / dynamicBindConfiguration when provisioning new VMs.

Oh and this also supports multiple environments per ScheduledEvent - Before this implementation only one environment could be choosen otherwise there were errors

[jggoebel]

Current identified issues are:

// TODO 13.01.2023: Fix issue where provisioning two of the same template in the samce VMC can cause overprovisioning for environments EDIT: 17.01.2023: Done with this

and

checking for limits when creating virtualmachinesets

Both existed before but could be fixed in future PRs

[jggoebel]

We should decide what happens when a VMClaim can not be fulfilled.
A session can have multiple VMClaims. Should the whole session be deleted when one claim can not be fulfilled?
Should we retry the vmclaim?

[jggoebel]

I tested what happens when we delete the session when one VMC can not be fulfilled and it looks good.
Also added a message in the UI so the user knows there is an issue with his session

[jggoebel]

Also fixed a 4-year old bug where on virtualmachinesets dangling VMs were produced when there are odd numbers of VMs (e.g. 3), but an equal number is used per user (e.g. 2). The third VM would be assigned but the claim could not be fulfilled. The VM would also not be deleted or unassigned when the session is terminated due to the fact that the VMs id was not being added to the VMClaim.