chore: split WireNetwork into three packages - WPB-15347

[caldrian]

WPB-15347 [iOS] Issues with linking dependencies

Issue

This PR attempts to prevent duplicate symbols of types in WireNetwork by splitting the framework into three packages each having only one dynamic product.

After merging the GitHub Actions caches should be cleared!

---

Checklist

• Title contains a reference JIRA issue number like [WPB-XXX].
• Description is filled and free of optional paragraphs.
• Adds/updates automated tests.

---

UI accessibility checklist

If your PR includes UI changes, please utilize this checklist:

• Make sure you use the API for UI elements that support large fonts.
• All colors are taken from WireDesign.ColorTheme or constructed using WireDesign.BaseColorPalette.
• New UI elements have Accessibility strings for VoiceOver.

[Copilot]

Copilot wasn't able to review this pull request because it exceeds the maximum number of files (300). Try reducing the number of changed files and requesting a review from Copilot again.

[github-actions]

Test Results

0 tests   0 ✅  0s ⏱️
0 suites  0 💤
0 files    0 ❌

Results for commit b0615b8.

♻️ This comment has been updated with latest results.

Summary: workflow run #29099982608
Allure report (download zip): html-report-76-chore_duplicate-symbols-WPB-15347

[github-actions]

Test Results – batch 1

  1 files  142 suites   14s ⏱️
563 tests 563 ✅ 0 💤 0 ❌
564 runs  564 ✅ 0 💤 0 ❌

Results for commit 557a03f.

♻️ This comment has been updated with latest results.

[github-actions]

Test Results – batch 0

196 tests   196 ✅  13s ⏱️
 36 suites    0 💤
  2 files      0 ❌

Results for commit 557a03f.

♻️ This comment has been updated with latest results.

[sonarqubecloud]

Quality Gate failed

Failed conditions
C Security Rating on New Code (required ≥ A)

See analysis details on SonarQube Cloud

💡 Need a hand with PR review? Try Gitar by Sonar!

[johnxnguyen]

question: why do we need a separate package for tests? A separate package for WireNetworkSupport makes sense, but I would expect that in WireNetwork there is simply a test target.

[caldrian]

If WireNetworkSupport is in a separate package, WireNetworkTests must be in a separate as well, otherwise we'd have a cyclic dependency, which is not allowed.

[samwyndham]

I think in practice 1 or 2 packages is enough. Some options include:

1. Have a single WireNetwork package with a single product containing multiple targets - WireNetwork & WireNetworkSupport. Also, update the automockable stencil so that mocks are generated inside an if DEBUG. I think this could be the easiest general approach to our project. This also means potentially using our mocks within SwiftUI previews which could be helpful.
2. Have 2 packages - WireNetwork & WireNetworkSupport. WireNetworkTests still live inside the WireNetwork package but do not depend on the WireNetworkSupport package. Instead as the mocks are generated just them generated in both WireNetworkTests and WireNetworkSupport.
3. Have 2 packages - WireNetwork & WireNetworkSupport. WireNetworkTests lives inside WireNetworkSupport - I don't like this option.

@caldrian what do you think?

[netbe]

removing myself from review since 2 reviewers are there already. Ping me if needed