FIX: Removes partners.one-specific tracking methods to make the library generic

[gautam-groupone]

Description

Fixes #605
The library previously included convenience methods (track_order_placed, track_sso_link_clicked, track_actionable_resolved) that are specific to partners.one's use case. These methods have been removed to keep the library generic and usable by anyone. Users can still achieve the same functionality by using the generic track() method directly.

Type of change

• New feature (non-breaking change which adds functionality).
• Bug fix (non-breaking change which fixes an issue).
• Enhancement (non-breaking change which improves an existing functionality).
• Breaking change (fix or feature that would cause existing functionality to not work as before).
• Sub-task of #(issue number)
• Chore
• Release

Detailed scenario

What was tested

• Verified that all generic methods (track(), set_user_property(), set_user_properties(), hash()) still work correctly
• Ran existing test suite to ensure no regressions
• Confirmed that partners.one-specific methods and their tests have been removed
• Validated that the library can still be imported and used with the generic API

How to test

Verify that removed methods (track_order_placed, track_sso_link_clicked, track_actionable_resolved) are no longer available

• Run test suite: uv run pytest

Affected Features & Quality Assurance Scope

Removed methods: track_order_placed(), track_sso_link_clicked(), track_actionable_resolved()

Technical description

Documentation

This change removes partners.one-specific convenience methods from the Tracking class. The library now only provides generic tracking functionality

New dependencies

None

Risks

None

Mandatory Checklist

Code validation

• I validated all the Acceptance Criteria. If possible, provide screenshots or videos.
• I triggered all changed lines of code at least once without new errors/warnings/notices.
• I implemented built-in tests to cover the new/changed code.

Code style

• I wrote a self-explanatory code about what it does.
• I protected entry points against unexpected inputs.
• I did not introduce unnecessary complexity.
• Output messages (errors, notices, logs) are explicit enough for users to understand the issue and are actionnable.

Unticked items justification

None

Additional Checks

• In the case of complex code, I wrote comments to explain it.
• When possible, I prepared ways to observe the implemented system (logs, data, etc.).
• I added error handling logic when using functions that could throw errors (HTTP/API request, filesystem, etc.)

[johngathure]

✅