chore: update config for data pipelines support

[mrehan27]

closes: MBL-619

Changes

• Updated CustomerIOConfig to align with Data Pipelines requirements
• Made all non-required values nullable, allowing optional configuration when constructing CustomerIOConfig
• Separated module configurations into individual files
• Re-exported configurations using same old path for compatibility
• Fixed SDK source and version in CustomerIOConfig, removing redundant code
• Adjusted sample app to compile, further updates will be handled in other tickets
• Added tests for CustomerIOConfig
• Resolved test failures caused by these changes

Code Changes

Before

import 'package:customer_io/customer_io_config.dart';

CustomerIOConfig(
  siteId: 'siteId',
  apiKey: 'apiKey',
  enableInApp: true,
  region: Region.us,
  trackingApiUrl: 'https://tracking.url.io/',
  autoTrackDeviceAttributes: true,
  autoTrackPushEvents: true,
  backgroundQueueMinNumberOfTasks: 10,
  backgroundQueueSecondsDelay: 30.0,
  logLevel: CioLogLevel.debug,
  pushClickBehaviorAndroid: PushClickBehaviorAndroid.activityPreventRestart,
);

After

import 'package:customer_io/customer_io_config.dart';

CustomerIOConfig(
  cdpApiKey: 'cdpApiKey',
  migrationSiteId: 'migrationSiteId',
  region: Region.us,
  logLevel: CioLogLevel.debug,
  autoTrackDeviceAttributes: true,
  apiHost: 'https://www.api.host.io/',
  cdnHost: 'https://www.cdn.host.io/',
  flushAt: 10,
  flushInterval: 30,
  inAppConfig: InAppConfig(siteId: 'siteId'),
  pushConfig: PushConfig(
    android: PushConfigAndroid(
      pushClickBehavior: PushClickBehaviorAndroid.activityPreventRestart,
    ),
  ),
);

[github-actions]

Sample app builds 📱

Below you will find the list of the latest versions of the sample apps. It's recommended to always download the latest builds of the sample apps to accurately test the pull request.

---

• amiapp_flutter: 157.1.0 (28846588)

[Shahroz16]

Looks good, few comments

[Shahroz16]

i think trackApplicationLifecycleEvents is not here as its part of another ticket, correct?

[mrehan27]

I focused mainly on Dart file changes here. native SDK implementation and testing will be handled in the other ticket you mentioned.

[Shahroz16]

thinking our load, if a user has provided migrationSiteId and not InAppConfig should we automatically handle it for them?

[mrehan27]

I initially thought the same, but doing it that way would mean losing flexibility in two scenarios:

• Disabling in-app messaging wouldn't be possible if migrationSiteId is provided
• If a user creates a new siteId, it could cause issues since migrationSiteId is supposed to remain the same, while in-app feature would require the new siteId

Keeping them separate gives us better control in these cases.