Enhance IMDS access detection to support cases where IMDSv2 is enforced (closes #8)

[christophetd]

Before:

• "Testing if IMDS is accessible" meant "Testing if IMDS could be accessed at the network level", without intelligence on what was returned nor any distinction between IMDSv1 and IMDSv2 (see "mkat test-imds-access" returns an invalid output when the node enforces IMDSv2 #8)

Now:

• We have 2 separate tests, one for IMDSv1 and one for IMDSv2
• The IMDSv1 test ensures that the response contains something - if not, it's likely that IMDSV2 is enforced and the endpoint returns a 401 error with empty content (so we're "secure")
• The IMDSv2 test works similarly, but handle timeouts differently due to how IMDS responds when IMDSv2 is enforced and max-response-hop is set to 1 (the TCP connection succeeds, but the subsequent socket read times out)

Sample result on an EKS cluster that has IMDSv2 enforced (but not blocked through a NetworkPolicy or response-max-hop=1)

[Frichetten]

Wow it's been a long time since I've looked at Go 😄 . From what I've deciphered it looks good to me.

I was going to nitpick that I didn't think Curl would hang indefinitely for dropped packets from IMDSv2 but based on the curl documentation it appears there is no default timeout.

[christophetd]

Yep I added the timeout after testing and seeing that it hangs. Thanks for the review!