Remove ACTIVE and SUCCEEDED task status type enums

[shreddedbacon]

These are no longer used, and have not been used for some time. I would like to remove them as part of #3351 but there are concerns because it is a backwards compatability break.

Remote controller no longer sends these statuses in the message payloads as of v0.4.1 (current v0.7.2) as we unified on builds and tasks using the same status types in #3114

Worth discussing if we consider holding off for Lagoon v3, or take it on under a minor version for Lagoon v2 (which would be v2.12.0 as of the creation of this discussion).

Anyone running a remote-controller older than v0.4.1 with the version of Lagoon that would remove these would be impacted by their removal. But anyone running that old of a version of remote-controller will probably have other issues they would need to contend with and ACTIVE/SUCCEEDED is probably the least of their problems.

Obviously I am FOR the removal of these.

[tobybellwood]

The way I think about it is that "Lagoon 3" will be a generational/architectural change, not a pure semver one. We can take our lead here from Kubernetes (and their willingness to embrace minor-release deprecations).

This should be ok to release under a minor release, given the time that has passed. I'd love to see a way that remotes/cores could leverage their versions to test compatibility though.

[rocketeerbkw]

Worth discussing if we consider holding off for Lagoon v3, or take it on under a minor version for Lagoon v2 (which would be v2.12.0 as of the creation of this discussion).

This should be ok to release under a minor release

The version of the api schema and the version of Lagoon have not been tied together before. It doesn't work, IMO, to say "it's ok to BC break this in a Lagoon minor release" because the api schema has no version (or you could consider it as being v1). This is why we have marked fields as @deprecated instead of removing them and why we've talked about schema changes in an "api v2." If we are treating the api like a "proper" public Graphql api, it doesn't matter what version of Lagoon is deployed, the schema shouldn't have any BC breaks, ever. We've broken BC in the past by accident and on purpose, but that's not the norm.

If we want to change it so that the schema is directly tied to the Lagoon version that's a major change and we'll need to communicate it appropriately.

[shreddedbacon]

Do we start versioning the API differently to Lagoon then? So we can introduce things without having to release Lagoon v3, 4, 5, 6, 7 etc whenever we want/need to change something somewhat minor like enums that aren't used anymore, but could be classed as BC break in graphql