Convert "InternalTektonResult" from string to int enum

[ghost]

Every Step that Pipelines runs emits a JSON object with metadata about its execution: the content of task results, a StartedAt timestamp, step exit codes etc etc.

The JSON object is passed back to the Tekton Controller by way of the "Termination Message", a Kubernetes feature that allows a Container to write a short amount of content that ends up back in the Pod's YAML. The emphasis here is on "short" - the termination message is limited to only a few thousand bytes, which in turn means that the JSON object Steps return needs to fit within this.

Several fields in the emitted JSON object are "InternalTektonResults", meaning that they are metadata which the Tekton Controller needs but that doesn't need to be surfaced in typically user-facing fields like Task Results. Each of these "internal-only" fields is given a "type" member in the Termination Message that looks like this:

{"type": "InternalTektonResult"}

Each entry in the JSON object that uses this type consumes, at minimum, 28 bytes of the termination message allotment (6 for "type" and 22 for "InternalTektonResult"). As we add more metadata which needs to be passed around this overhead will grow.

For the longer term we've discussed methods of avoiding the Termination Message altogether. In the short term we could easily curtail this wastage by changing "type" from a string to an int. e.g. {"type": 0}. The int would then map to an enum of possible types (of which there are few). This would drop the overhead of each internal result from 28 bytes to 7.

[sm43]

/assign

[ghost]

We could drop this even further by switching from "type" to (for example) "_" or "t".

Revisiting this particular idea - I don't think it's possible to achieve a field rename without modifying our swagger or openapi generated files. This complicates the problem a little bit - the termination message json object is not a public-facing api (not intended for external consumption) so it's a bit weird that it even shows up in these places at all.

Anyway, long story short: I don't think changing the "type" field to be named "t" or "_" is a good idea anymore so I'm going to remove that bit from the Issue description. I should have checked what the impact of this would be before suggesting it.