refactor: Updated Receiver to Handler for Sync Metric functionality. …

[destrex271]

References the current upstream version of pgwatch3_rpc_receivers where we have separated both the receiver and the sync metric handler.

A new type called Handler now handles the Sync Metric calls in the receivers: https://github.com/destrex271/pgwatch3_rpc_server/blob/1cb1f44d237ce5817831194c9285c20397277fc2/cmd/csv_receiver/main.go#L32

[coveralls]

Pull Request Test Coverage Report for Build 10617031936

Details

• 1 of 1 (100.0%) changed or added relevant line in 1 file are covered.
• 6 unchanged lines in 1 file lost coverage.
• Overall coverage decreased (-0.1%) to 28.378%

---

Files with Coverage Reduction	New Missed Lines	%
internal/log/log_broker_hook.go	6	59.3%
<!--	Total:	6		-->

Totals
Change from base Build 10613049886:	-0.1%
Covered Lines:	1380
Relevant Lines:	4863

---

💛 - Coveralls

[pashagolub]

No, we will keep it Receiver. I don't see any point in renaming things. It is the same object handling all functions, at the moment UpdateMeasurements and SyncMetrics. If RPC sink has two different objects dealing with it, it's the choice of the author. pgwatch considers RPC sink as a single interface supporting all (at the moment 2) methods.

[destrex271]

No, we will keep it Receiver. I don't see any point in renaming things. It is the same object handling all functions, at the moment UpdateMeasurements and SyncMetrics. If RPC sink has two different objects dealing with it, it's the choice of the author. pgwatch considers RPC sink as a single interface supporting all (at the moment 2) methods.

Ok! I'll make the required changes in receivers repo