feat: Record AWS Lambda coldstarts

[serkan-ozal]

Which problem is this PR solving?

Adds recording AWS Lambda invocation coldstarts as Lambda invocation span attributes.

Short description of the changes

Decides whether an AWS Lambda invocation is coldstart or not by taking care of the following cases:

• Non-first invocations are warm, not coldstart
• If sandbox environment is initialized with provisioned concurrency, every invocations are warm, not coldstart
• If sandbox has been initialized proactively before the actual request, every invocations are warm, not coldstart

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 90.67%. Comparing base (dfb2dff) to head (8159ac7).
Report is 231 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #2403      +/-   ##
==========================================
- Coverage   90.97%   90.67%   -0.30%     
==========================================
  Files         146      156      +10     
  Lines        7492     7628     +136     
  Branches     1502     1575      +73     
==========================================
+ Hits         6816     6917     +101     
- Misses        676      711      +35     

Files with missing lines	Coverage Δ
...-instrumentation-aws-lambda/src/instrumentation.ts	95.21% <100.00%> (+1.53%)	⬆️

... and 75 files with indirect coverage changes

[pragmaticivan]

🤯

[dyladan]

Looks reasonable to me. I think this can be merged. I left a minor suggestion, but if you don't want to do it that's fine. Just comment and we'll merge this when you're ready.

[serkan-ozal]

Looks reasonable to me. I think this can be merged. I left a minor suggestion, but if you don't want to do it that's fine. Just comment and we'll merge this when you're ready.

@dyladan Are you suggesting to update semconv package and update all semconv attributes in all places accordingly? If so, I think it should be done in a separate PR. I have used SEMATTRS_... properties, because as far as I see, it is the general approach used by other instrumentation plugins too.

[dyladan]

Looks reasonable to me. I think this can be merged. I left a minor suggestion, but if you don't want to do it that's fine. Just comment and we'll merge this when you're ready.

@dyladan Are you suggesting to update semconv package and update all semconv attributes in all places accordingly? If so, I think it should be done in a separate PR. I have used SEMATTRS_... properties, because as far as I see, it is the general approach used by other instrumentation plugins too.

I had been thinking only the newly introduced attribute would use the new format. The old formats are still exported for backward compatibility. but leaving it for a followup is also fine.