feat: isolate server ut communication

[cisse21]

Description

< Replace with adequate description for this PR as per Pull Request document >

Linear Ticket

< Replace with Linear Link ( create or search linear ticket) or >

Security

• The code changed/added as part of this pull request won't create any security issues with how the software is being used.

[codecov]

Codecov Report

Attention: Patch coverage is 28.19149% with 675 lines in your changes missing coverage. Please review.

Project coverage is 74.01%. Comparing base (aaae529) to head (5c1c564).

Files with missing lines	Patch %	Lines
...ssor/internal/user_transformer/user_transformer.go	6.35%	221 Missing ⚠️
...trackingplan_validation/trackingplan_validation.go	6.33%	207 Missing ⚠️
...destination_transformer/destination_transformer.go	6.69%	195 Missing ⚠️
processor/internal/http_client/http_client.go	44.73%	21 Missing ⚠️
...or/internal/transformer_utils/transformer_utils.go	0.00%	17 Missing ⚠️
processor/processor.go	94.91%	5 Missing and 1 partial ⚠️
processor/transformer/manager.go	50.00%	6 Missing ⚠️
processor/trackingplan.go	92.85%	1 Missing ⚠️
...ger/transformation/transformationStatusUploader.go	66.66%	1 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##           master    #5430      +/-   ##
==========================================
- Coverage   74.79%   74.01%   -0.78%     
==========================================
  Files         440      447       +7     
  Lines       61670    62406     +736     
==========================================
+ Hits        46125    46191      +66     
- Misses      13002    13673     +671     
+ Partials     2543     2542       -1     

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

[ktgowtham]

1. Can I assume the implementation logic(in user_trans, dest_trans) is exactly same as copied from transformer.go? planning to skip reviewing that part for just skim it through.

2. router transformer will remain as is? it’s only transformation in processor that we’re splitting out rt?

3. Looks like we’ve not replaced function calls to use the new sendrequest function. do we plan to do that in follow up PR?

4. Are we okay to have types.TransformerEvent as param for all implementations(in ServiceClient -> SendRequest)? Will we lose flexibility to have same struct? or is it going to be same and we choose what to populate in that struct?

[cisse21]

Can I assume the implementation logic(in user_trans, dest_trans) is exactly same as copied from transformer.go? planning to skip reviewing that part for just skim it through.

Yeah... I just got rid of a few things here and there which are relevant to individual components but yeah in this PR we can assume that it is going to be the same

router transformer will remain as is? it’s only transformation in processor that we’re splitting out rt?

Yes... it is only the processor transformer module we are splitting out

Looks like we’ve not replaced function calls to use the new sendrequest function. do we plan to do that in follow up PR?

That is the only part remaining where I will put it under a flag so that we can switch between older and newer implementation

Are we okay to have types.TransformerEvent as param for all implementations(in ServiceClient -> SendRequest)? Will we lose flexibility to have same struct? or is it going to be same and we choose what to populate in that struct?

Didn't want to make too many changes in one PR but the idea is to abstract out things in this PR and then change the structs with the appropriate data over the subsequent PR's

[Sidddddarth]

consider dropping endless backoff here too

[cisse21]

This is needed from what I discussed with @Jayachand