[processor/k8sattr] Use RFC3339 format for creation timestamp value

[bryan-aguilar]

Description: This PR changes the format used for the k8s.pod.start_time value. Previously the .String() method was used but documentation for that says it should only be used for debugging. Instead use .MarshalText() which formats in RFC3339.

I have listed this as a breaking change because it is possible that end users are making assertions on the format of this timestamp value.

Timestamp output:
before: 2023-07-10 12:34:39.740638 -0700 PDT m=+0.020184946
after 2023-07-10T12:39:53.112485-07:00
Link to tracking Issue: n/a

Testing: Updated unit tests.

Documentation: Add blurb at bottom of readme

[TylerHelmuth]

@bryan-aguilar can you include in your description a before and after example of how the change affects the timestamp.

[bryan-aguilar]

@TylerHelmuth done, thanks for the suggestion. Do you think this should be in the changelog entry also?

[TylerHelmuth]

@bryan-aguilar ya in the subtext section

[TylerHelmuth]

This component is ubiquitous enough that we probably need to follow our deprecation process and utilize feature gates for this breaking change. @dmitryax what do you think?

[dmitryax]

This component is ubiquitous enough that we probably need to follow our deprecation process and utilize feature gates for this breaking change. @dmitryax what do you think?

Sounds good to me. @bryan-aguilar can you please run it by a feature gate and show a warning if this attribute is enabled?

[bryan-aguilar]

Yup, will do.

[bryan-aguilar]

@dmitryax Pod start time is enabled by default which would lead to us always showing a warning. Is this in line with what you had in mind?

[dmitryax]

Pod start time is enabled by default which would lead to us always showing a warning. Is this in line with what you had in mind?

It is enabled by default, but we don't need to show the warning for users specifying extract::metadata explicitly without k8s.pod.start_time

[bryan-aguilar]

@TylerHelmuth @dmitryax I have added a feature gate for this change. Indicating in the warning that the default behavior will be changed in v0.83.0. From what I could tell there was not a better mechanism to signal this other than a logging statement.