feat(inputs.sqlserver): Support Azure federated token from env variables

[kauanmodolo]

Summary

This change introduces first-class support for Azure federated workload identity in the SQL Server input. When the environment exposes AZURE_CLIENT_ID, AZURE_TENANT_ID, and AZURE_FEDERATED_TOKEN_FILE, the plugin now reads the JWT assertion file, exchanges it against [https://login.microsoftonline.com/<tenant>/oauth2/v2.0/token](https://login.microsoftonline.com/%3Ctenant%3E/oauth2/v2.0/token%60) for the [https://database.windows.net/.default](https://database.windows.net/.default%60) scope, and delivers the resulting access token to the driver. This flow mirrors the documented curl exchange from Microsoft, meaning clusters that rely on Kubernetes workload identities (or other OIDC federations) no longer need managed identities or client secrets. If the variables are absent, the plugin seamlessly falls back to the existing Azure Identity / ADAL logic, so no behavioral change occurs for prior configurations.

The implementation carefully surfaces detailed error messages when the assertion file cannot be read, the HTTPS call fails, or the OAuth response doesn't contain an access token. This ensures operators can diagnose configuration issues quickly. By front-loading the federated path, we enable Telegraf to participate in modern secretless deployments that use short-lived tokens issued by federated identity providers.

Checklist

• No AI generated code was used in this PR

• AI generated code used in this PR follows the InfluxData Policy on AI-Generated Code Contributions

Related issues

resolves #15404

[telegraf-tiger]

Thanks so much for the pull request!
🤝 ✒️ Just a reminder that the CLA has not yet been signed, and we'll need it before merging. Please sign the CLA when you get a chance, then post a comment here saying !signed-cla

[kauanmodolo]

!signed-cla

[srebhan]

Thanks for your contribution @kauanmodolo! It seems like you "hand-crafted" this and I wonder if you can't use the functionality of the Azure SDK instead. This would add the benefit that we don't need to maintain the URLs etc if Microsoft decides to change something.

[luizfelmach]

Thanks for your contribution @kauanmodolo! It seems like you "hand-crafted" this and I wonder if you can't use the functionality of the Azure SDK instead. This would add the benefit that we don't need to maintain the URLs etc if Microsoft decides to change something.

Using the https://github.com/Azure/azure-sdk-for-go/blob/sdk/azidentity/v1.13.1/sdk/azidentity/client_secret_credential.go#L47 looks the better approach.

[srebhan]

@kauanmodolo any update?