[FEATURE]: Send instance guid on webhook structure

Summary

Make instance guid an argument so we know pod origin on HITL

Additional Context

No response

Upload screenshots

No response

Searched Issues

No similar issues found

Code of Conduct

I agree to follow this project's Code of Conduct

@dhable

Again this is more governance transparency @dhable - it might be worth generating an identifying guid for what instance of aura a HITL interrupt came from

@Shearerbeard

The easiest method for generating a guid would just be to generate a hash based off of the current timestamp at boot - e.g. UUID v4. We might also want something unique but stable across restarts to make it easier to correlate HITL requests across a longer time frame. We could build a guid using the following:

instance_guid = uuidv5(aura_ns, instance_fingerprint)
  where
    aura_ns is something like "mezmo.com/aura:v1" and used to identify the 
    instance_fingerprint is both environment and config seed to identify where and what is running

Since UUIDv5 is a stable hash, we should be able to track the same instance across restarts if we pick sane fingerprint values. These values are a fixed pattern concatenated bytes, prefixed by the number of bytes that follow to avoid ambiguity with multiple byte fields. Thus name="ab", alias="c" → 2:ab1:c vs name="a", alias="bc" → 1:a2:b

To compute a unique environment seed (i.e. where the aura process is running), aura would use the following list in order:

AURA_INSTANCE_ID environment variable value. This allows for overriding the remaining values if desired.
k8s downward API ("{POD_NAMESPACE}:{POD_NAME}")
machine_uid crate to determine a HW identifier (/etc/machine-id for Linux, gethostuuid() for Mac, MachineGuid registry value for Windows)
If no value can be determined, then generate a random UUIDv4 value and emit a warning log with the suggestion to set AURA_INSTANCE_ID.

To compute a unique config seed (i.e. what the process is running), aura would use the following list in order:

[agent].instance_seed (new property) from the config file
Agent name and alias fields ("{[agent].name}{[agent].alias}"). Since the agent name is required in the config, we should always have a value available. Does it make sense to guard against an empty string at this point?

This identify value would then be exposed through the the web API, the session info, etc. for discovery by a consumer.

While this makes it possible to identify a unique process/config combo (a pod/host running agent xyz), there is still an open question of how to discover these values. Does each aura instance publish them on boot though a webhook event stream? How does a consumer find all the values If there are multiple pods backing a k8s service? Walk a headless service? I get the sense that this card is about just establishing the unique values and then worrying about the communication of those values later.

cc: @Shearerbeard / @henryjandrews

This works for me, the VFS session_guard work needs an instance guid so I'll probably use this for that work as well

feat(instance-id): add stable per-agent instance identity

feat(instance-id): expose instance id in governance info, repl, and api