Identify replica sets based on owner info provided by DCP, group applications by their replica set in resource dropdowns, add tests for console logs application resource grouping

[adamint]

Currently, we are grouping applications based on whether their display names are identical, instead of using the ExecutableReplicaSet property from DCP.

The approach I took was

1. Flow owner information, which includes the above property, from DCP through to the dashboard frontend
2. Modify the 'application grouping' view model creation logic to use the real replica set for a resource
3. Replace (replica set) with (application) on traces/logs resource dropdowns, because the OTLP applications there can be grouped, but are not replica sets.
   
4. Add a test around behavior for console logs view model creation (Unit Tests for Resource Name display text #1411)
    
   Fixes Unit Tests for Resource Name display text #1411
   Fixes Different instances of same resource type grouped as replicas in dashboard #4103
   Fixes Identify replica sets for dashboard #1233

Microsoft Reviewers: Open in CodeFlow

[adamint]

@JamesNK Could you advise on what to do about ResourceOutgoingPeerResolverTests.NameAndDisplayNameDifferent_MultipleInstances_ReturnName - does the previous behavior of ResourceViewModel.GetResourceName need to stay the same for containers?

[JamesNK]

It's odd for something to have multiple owners. What are scenarios that would cause multiple owners?

cc @karolz-ms

[karolz-ms]

This is a K8s API concept and probably not the best name: it is a list of objects that depend on the given object. https://kubernetes.io/docs/reference/kubernetes-api/common-definitions/object-meta/#System Most common scenario is when there is some sort of N:M relationship that is modeled as a separate object, the motivation for multiple owners being keeping the model consistent and cascade deletion.

For example (we are not doing this today, but we might in future): an Endpoint is exposed on a Network, implements a Service, and is implemented by an instance of a Container or Executable. The Network, Service, and implementing Container/Executable could all be "owner" objects.

[JamesNK]

I'm fine with the changes in this PR except everything to do with getting and returning Owner info to the dashboard. It doesn't fix anything, it makes things more complicated, and it adds fields to the proto contract that we should think careful about before changing.

Think Owner changes should be removed from this PR.