[extension/googlecloudlogentryencoding] fix protocol parsing for ALPN identifiers

[tpilewicz]

Description

Before: The googlecloudlogentryencoding extension cannot parse HTTP logs from Google Cloud load balancers because they provide ALPN identifiers for protocol (like h2), while the extension expects the HTTP/2 format.

After: The extension is able to parse these logs and identify the h2 and h3 ALPN identifiers as valid protocols.

Assisted-by: Claude Opus 4.6

Link to tracking issue

Fixes #45214

Testing

Unit tests are added for the h2 and h3 cases.

[linux-foundation-easycla]

The committers listed above are authorized under a signed CLA.

• ✅ login: tpilewicz / name: tpilewicz (8c39cf9)

[github-actions]

Welcome, contributor! Thank you for your contribution to opentelemetry-collector-contrib.

Important reminders:

• Please review our Contributing Guidelines.
• Don't forget to sign the Contributor License Agreement (CLA) if you haven't already.

A maintainer will review your pull request soon. Thank you for helping make OpenTelemetry better!

[constanca-m]

This PR #47621 would fix this issue. Would this work for you @tpilewicz ? Can we close this PR as a duplicate?

[tpilewicz]

@constanca-m works for me as long as we fix the encoding errors! Note however this slight difference:

• this PR interprets h2 as protocolName: "http", protocolVersion: "2"
• [extension/encoding/googlecloudlogentryencoding] accept short ALPN protocol tokens (h2, h3) #47621 interprets h2 as protocolName: "h2"

Users might prefer to see the former in their telemetry, to get something consistent with the format emitted when HTTP/1.1 is received.

[constanca-m]

Users might prefer to see the former in their telemetry, to get something consistent with the format emitted when HTTP/1.1 is received.

can we discuss this on the PR #47621 so we get alignment there? Since we have two PRs trying to fix the same issue, we need to find a unified approach together

[tpilewicz]

Putting a comment there to start the discussion