golang callaback: add DownstreamSslConnection

[fl0Lec]

adding downstreamSslConnection to have 1:1 matching with Lua features

Commit Message: adding downstreamSslConnection to have 1:1 matching with Lua features
Additional Description:
Risk Level: Low
Testing: Integration test
Docs Changes: No
Release Notes: Yes
Platform Specific Features:
[Optional Runtime guard:]
[Optional Fixes #Issue]
[Optional Fixes commit #PR or SHA]
[Optional Deprecated:]
[Optional API Considerations:]

[repokitteh-read-only]

As a reminder, PRs marked as draft will not be automatically assigned reviewers,
or be handled by maintainer-oncall triage.

Please mark your PR as ready when you want it to be reviewed!

🐱

Caused by: #43480 was opened by fl0Lec.

see: more, trace.

[doujiang24]

@fl0Lec , Nice work!

[wdauchy]

nice work on the feature parity with Lua, the Go interface and tests look solid. I have a few concerns mostly around the C API surface area and some consistency nits.

[wdauchy]

the interface contract says "returns nil if the connection is not secured with SSL/TLS". panic("implement me") will crash at runtime instead. consider returning nil here to match the documented behavior, same as the other unimplemented stubs that return zero values.

[fl0Lec]

Returning nil here would actually be misleading, since per the interface contract nil specifically means "the connection is not secured with SSL/TLS". That would be incorrect - the connection might be secured, we just haven't implemented this functionality for network filters yet.

The panic("implement me") pattern is consistent with other unimplemented methods in this file (e.g., GetRouteName, FilterChainName, Protocol, ResponseCode, DynamicMetadata, UpstreamClusterName, etc.). The network filter is less commonly used than the HTTP filter, so these stubs exist to fulfill the Go interface while signaling that the functionality isn't available yet.

If/when we implement SSL connection support for network filters, we'll replace the panic with the actual implementation.
Which could be done in a followup PR if needed

[wdauchy]

looks good to me. the refactoring to use EnvoyValue enum dispatch with getStringValue/getIntegerValue/getStringsValue is much cleaner than the original 21 separate C API functions. the null byte separator for SANs and the streamInfo() revert are also addressed. nice work.