Add instance_guid field in Process Stats response

[tcdowney]

A short explanation of the proposed change:

• Display the Diego instance identifier as part of the Process Stats
  response. This id is unique for each actual LRP instance and can be used
  as a substitute for the integer index id.
• Eirini does not support this in their API at this time, so the OPI
  variant of the instances stats reporter returns an empty string for this
  field. In the future, if Eirini is enhanced to provide this we can
  update that client.
• Issue: Feature Request: Include LRP instance_id in Process Stats response #2819

An explanation of the use cases your change solves:

The issue (#2819) describes this use case in more detail. The summary though is this can help developers debug their apps (this id is logged by app containers) and provide a pathway for clients to provide other container ids than just the integer index.

• I have reviewed the contributing guide

• I have viewed, signed, and submitted the Contributor License Agreement

• I have made this pull request to the main branch

• I have run all the unit tests using bundle exec rake

• I have run CF Acceptance Tests

[tcdowney]

@Gerg some additional context for this change:

On Korifi we're wanting to support workloads other than StatefulSets (e.g. Deployments, knative Services, etc.) so we're working toward reducing the reliance of system components on the numerical indexing of app instances. I'll be putting out a proposal / some sort of design doc to start discussing this in more detail later this week, but I see this change as a first step toward that.

[tcdowney]

I'm putting this into draft state. I was looking at the AppRecipeBuilder and noticed that instance_id is that metric tag we're adding and it corresponds to instance index. We are calling this the process_instance_id on metrics/logs so maybe that name should be used. Worth discussing I think.

cloud_controller_ng/lib/cloud_controller/diego/app_recipe_builder.rb

Line 108 in 7698bc4

'process_instance_id' => METRIC_TAG_VALUE.new(dynamic: METRIC_TAG_VALUE::DynamicValue::INSTANCE_GUID),

[Gerg]

It's a little odd that we call index instance_id in the metrics tags. Looks like it came from this story.

index/guid is the most intuitive to me, but I could see other options. Process.instance.process_instance_id sounds a bit redundant.

[tcdowney]

@Gerg

Yeah, I started calling it instance_guid here in the proposal around this stuff here:
https://docs.google.com/document/d/118yYN4WGj1F2si8gk94xFZsYdewtOKoqO2Dv-1I-PgE/edit

[Gerg]

What about just guid?

[tcdowney]

cc @zrob

[tcdowney]

What about just guid?

I went with instance_guid. There are other fields prefixed with instance_ and it felt less ambiguous since this is what the field is called on the ActualLRP.
https://github.com/cloudfoundry/bbs/blob/main/docs/030-lrps.md#instance_guid

[tcdowney]

The docs failure is unrelated to my change. It looks like some of the npm packages we're using for the doc link checker are not working with modern node.js? I don't have much experience with all that so not sure, but I feel like we can ignore this for this PR.