fix(node): Only set DeviceContext.boot_time if os.uptime() is valid

[Lms24]

When creating the DeviceContext in the Node SDK Context integration, we calculate the boot time based on os.uptime. However, as reported in #5856, os.uptime might not always be available or return undefined (I couldn't figure out which of the two cases actually was responsible).

This PR quickly fixes this bug by simply not setting the boot time in case we don't get a valid up time. It also adds two basic tests for this behaviour. I opted to not set the boot time instead of e.g. defaulting to 0 for uptime because IMO this creates a false boot time that probably causes more confusion than not having it. However, as my context on the Context integration (👀) is limited, I'm interested in other opinions on this. cc @timfish

fixes #5856

[AbhiPrasad]

Let’s approve to unblock, maybe even cut a patch for it (I’ll let you make the judgement call there), but weird that this happens, let me do some research on my end as well.

[Lms24]

maybe even cut a patch for it

While I don't think this has super high prio, I think there's nothing holding us back from releasing a patch. Will coordinate with the rest of the team

[timfish]

We might also want to wrap more of this code in try/catch Just In Case™️.

If we were only dealing with vanilla Node.js we can rely heavily on the types + tests but with all these node/v8 derived/patched runtimes it feels like a lot of guesswork!

The user report shows it failing on os.uptime but with that fixed it might then fail on the CPU stuff...

[Lms24]

Good Point, Tim. I did a little digging and I think for the azure use case we're probably good because os.uptime seems to be the only thing that returns undefined. Left a small comment about this in the bug report issue.

I think though, the try/catch blog seems like a good suggestion because who knows what other runtimes permit/return.