fix: omit creating cold start on LMI

[duncanista]

What does this PR do?

Omit creating cold start tracing on LMI

Motivation

We want to provide a better experience when a new sandbox is initialized and the gap between invocation and init is quite long, and SVLS-8482

Testing Guidelines

Unit tests

Additional Notes

Metrics are not affected since we still want to know how many sandbox are span up.

Types of Changes

• Bug fix
• New feature
• Breaking change
• Misc (docs, refactoring, dependency upgrade, etc.)

Check all that apply

• This PR's description is comprehensive
• This PR contains breaking changes that are documented in the description
• This PR introduces new APIs or parameters that are documented and unlikely to change in the foreseeable future
• This PR impacts documentation, and it has been updated (or a ticket has been logged)
• This PR's changes are covered by the automated tests
• This PR collects user input/sensitive content into Datadog
• This PR passes the integration tests (ask a Datadog member to run the tests)

[purple4reina]

Question. How does LMI handle cold starts then? Does the customer ever see their invocations waiting on a cold start? or does it always do something like proactive init?

[purple4reina]

Question. Will you also be doing this for python? I assume the universal languages will be handled already as their cold start spans are created in the extension.

[duncanista]

@purple4reina

How does LMI handle cold starts then? Does the customer ever see their invocations waiting on a cold start? or does it always do something like proactive init?

As provisioned concurrency, or when a sandbox is proactively initialized, that's how the span would look on the trace, now we are avoiding having this experience in LMI specifically

Will you also be doing this for python? I assume the universal languages will be handled already as their cold start spans are created in the extension.

Yes, and for those, the change has been already made on the extension