Fix: non-blocking ChannelTransferProgress handling

[black-night-heron]

Fixes #32.

In the current implementation, time.Sleep(50 * time.Millisecond) is called whenever a ChannelTransferProgress event is triggered, and the channel handling these events is unbuffered. This setup causes the reader/writer processes to be blocked, subsequently slowing down both upload and download speeds.

This pull request proposes a solution by leveraging the built-in throttle feature of the progressBar instead of using time.Sleep.

---

Possibility of a Non-blocking Send

Actually, integrating the progressBar's throttle feature introduces overhead due to various checks and locks. An alternative improvement could be the implementation of non-blocking sends, which might further enhance performance:

--- a/sdk/client.go
+++ b/sdk/client.go
@@ -204,7 +204,11 @@ func (client *Client) signalTransferProgress(b int64) {
        if !client.UseTransferSignals {
                return
        }
-       client.ChannelTransferProgress <- b
+
+       select {
+       case client.ChannelTransferProgress <- b:
+       default:
+       }
 }

However, this change in the SDK could potentially lead to some issues and may break other SDK users. For instance, the last progress update might be dropped, which could result in an incomplete progress bar display:

Uploading 100MB.bin...          99% |███████████████████ | (105/105 MB, 5.1 MB/s) [32s:0s]

[virtualzone]

Thanks for your contribution @black-night-heron !