feat: add FederatedLogSetup, AwsConnection, and FederatedLogPartition entity support to pipelinecontrol

[voorepreethi]

Summary
Adds support for three new entity types in the pipelinecontrol package: FederatedLogSetupEntity, AwsConnectionEntity, and FederatedLogPartitionEntity. These enable full lifecycle management of federated log infrastructure resources via the Entity Management API.

Changes
New API Methods
Federated Log Setup

EntityManagementCreateFederatedLogSetup / WithContext — create a Federated Log Setup entity
EntityManagementUpdateFederatedLogSetup / WithContext — update an existing Federated Log Setup entity
Federated Log Partition

EntityManagementCreateFederatedLogPartition / WithContext — create a Federated Log Partition entity
EntityManagementUpdateFederatedLogPartition / WithContext — update an existing Federated Log Partition entity
AWS Connection

EntityManagementCreateAwsConnection / WithContext — create an AWS Connection entity
Search

GetEntitySearch / WithContext — search entities with filters and cursor-based pagination

Tests
Unit Tests (27 total)
Federated Log Setup (6)

Create: success, with-context, error
Update: success, with-context, error
Federated Log Partition (6)

Create: success, with-context, error
Update: success, with-context, error
AWS Connection (3)

Create: success, with-context, error
GetEntity (2)

Returns FederatedLogSetupEntity type assertion
Returns AwsConnectionEntity type assertion
GetEntitySearch (4)

Success, with-context, empty results, error

Integration Tests
TestIntegrationEntityManagement_FederatedLogSetup_CRUD — full create/read/update/delete cycle (gated by RUN_FEDERATED_LOG_SETUP_TEST=true)
TestIntegrationEntityManagement_FederatedLogSetup_Create — standalone create test with real credentials (gated by env vars)

[codecov-commenter]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 31.92%. Comparing base (25308d5) to head (4256acc).
⚠️ Report is 9 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #1377      +/-   ##
==========================================
- Coverage   33.04%   31.92%   -1.12%     
==========================================
  Files         136      140       +4     
  Lines        6256     6737     +481     
==========================================
+ Hits         2067     2151      +84     
- Misses       3990     4386     +396     
- Partials      199      200       +1     

Flag	Coverage Δ
unit	31.92% <100.00%> (-1.12%)	⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[maya-jha]

Can you please mention which files are auto generated and which files are updated by you?

[maya-jha]

how do we decide this?

[voorepreethi]

This is the reason : max_query_field_depth = deepest nesting level in the GraphQL response. AwsConnection has 3 levels (entity → credential → assumeRole), FederatedLogSetup and FederatedLogPartition have 4 levels (entity → metadata → createdBy → __typename). Tutone uses this to know how deep to generate fields.

[maya-jha]

Is this file auto generated?

[voorepreethi]

No

[maya-jha]

I see fleet related entity here: https://github.com/newrelic/newrelic-client-go/tree/30c29f31adbfcfcd7c9f41b9da6b4473284c9e6c/pkg/fleetcontrol . Can we get some guidance from the owning team of this repo whether we should create a new folder for federated logs? How much effort required if we move to a dedicated folder?

[voorepreethi]

Files are not autogenerated. Code is .