Add timestamp to BEP redis key behind feature flag

[blakehatch]

Add some kind of simple timestamp value after the sequence number, this will help with sorting in some client setups for this server that need to do sorting without having to track build_ids and sequences.

            store
                .update_oneshot(
                    StoreKey::Str(Cow::Owned(format!(
                        "BuildToolEventStream-{}-{}-{}",
                        &stream_id.build_id, &stream_id.invocation_id, sequence_number,
                    ))),
                    buf.freeze(),
                )
                .await
                .err_tip(|| "Failed to store PublishBuildToolEventStreamRequest")?;

The config would need to have an additional option under the config that enables this to be optionally added to the key. This would be under "experimental_pub_sub_channel" labeled something like "experimental_pub_sub_timestamp".

    "BEP_STORE": {
      "redis_store": {
        "addresses": [
          "${BEP_REDIS_STORE_URL:-redis://redis-headless:6379/2}"
        ],
        "experimental_pub_sub_channel": "{{ .observed.composite.resource.spec.namespace.bep.channel }}"
      }

[MarcusSorealheis]

@blakehatch In other words?:

    "BEP_STORE": {
      "redis_store": {
        "addresses": [
          "${BEP_REDIS_STORE_URL:-redis://redis-headless:6379/2}"
        ],
        "experimental_pub_sub_channel": "{{ .observed.composite.resource.spec.namespace.bep.channel }}"
        "experimental_pub_sub_timestamp": "{{ .observed.composite.resource.spec.namespace.bep.timestamp }}" // <-- New value
      }

Or, does it need something else? Is this when the channel was created? Is this for how long it has lived? I think that's the only detail that is unclear to me here.

[blakehatch]

Yes exactly @MarcusSorealheis! It would look exactly like that in the config and then the data would send over Redis with a timestamp. We likely don't need this for the feature it was originally intended because we have a deserializing step on the payload (which contains a timestamp) but this still could be useful in the future for simpler problems in the future that require time-based sorting in Redis. I might close this issue however since there's no immediate need for the feature.