Update Adaptive Runtime to add telemetry client to the TurnState

[garypretty]

Fixes #5504

Description

PR to ensure adaptive dialog events are being logged correctly.

Specific Changes

• Ensures the IBotTelemetryClient is added to the TurnState, which then ensures adaptive dialog events are correctly captured.
• Amends the value of dialogId captured on the AdaptiveDialogAction event to use the parent dialog Id.
• Adds an Instance Id property to the AdaptiveDialogStart / AdaptiveDialogComplete / AdaptiveDialogAction events to ensure they can be correlated within App Insights queries (this brings parity with waterfall dialog telemetry events).

[carlosscastro]

Can we see a test where if instanceId is null ActionScope:323, nothing breaks? This is my main concern with this PR

[carlosscastro]

If we test that we'd be safe.

[garypretty]

Removed.

[garypretty]

Removed instanceId addition within this PR as requested

[johnataylor]

How about having the telemetry middleware add the telemetry client to the turn state? there are some advantages to taking that approach

[johnataylor]

lets evaluate adding the telemetry client to the turn state from the telemetry middleware

(I have a DRAFT pr that plays with this idea. It has the advantage of keeping the telemetry stuff basically in one place, however, fails to model the dependency the AdaptiveDialog has on IBotTelemetryClient - so I'm not sure its any better)

[johnataylor]

@carlosscastro @garypretty this is what the alternative might look like #5535

[johnataylor]

What you are saying here is that an AdaptiveDialog depends on a a IBotTelemetryClient. Is that what you intend?

So assuming it is, then by extension the Dependency Injection mechanism is pulled in. In which case take a look at the AddBotRuntimeTelemetry function in the ServicesCollectionExtensions.

What would make things more consistent would be to remove the lines:

            if (string.IsNullOrEmpty(telemetrySettings?.Options?.ConnectionString) && string.IsNullOrEmpty(telemetrySettings?.Options?.InstrumentationKey))
            {
                services.AddSingleton<IBotTelemetryClient, NullBotTelemetryClient>();
            }

After all you are applying the default in your constructor.

And then replace the AddSingleton with a TryAddSingleton (line 139) and then edit the lambda to apply the defaulting to NullBotTelemetryClient if the GetService returns null (using these inline lambdas is not great - it just shows we haven't modeled the dependencies.) and then get rid of this lambda in R14

So I'm thinking I actually quite like this change - because its modeling the dependency explicitly - however I do think we should fix up AddBotRuntimeTelemetry as part of this PR to make things consistent.

[johnataylor]

I think fixing the AddBotRuntimeTelemetry is too bigger change at this point