Refactor: refactor the RadasSender

[ligangty]

• rename radas_signature_handler.py to radas_sign.py
• change RadasSender logic:
  • add retry logic
  • add error handling
  • avoid duplicate message sending
• use a global RadasConfig instead created one in each Radas class

[coveralls]

Pull Request Test Coverage Report for Build 15433363274

Details

• 64 of 101 (63.37%) changed or added relevant lines in 4 files are covered.
• 1 unchanged line in 1 file lost coverage.
• Overall coverage increased (+0.3%) to 65.359%

---

Changes Missing Coverage	Covered Lines	Changed/Added Lines	%
charon/cmd/cmd_sign.py	0	3	0.0%
charon/config.py	0	10	0.0%
charon/pkgs/radas_sign.py	63	87	72.41%

Files with Coverage Reduction	New Missed Lines	%
charon/cmd/cmd_sign.py	1	0.0%

Totals
Change from base Build 15338844925:	0.3%
Covered Lines:	2149
Relevant Lines:	3288

---

💛 - Coveralls

[shokakucarrier]

And one other thing is in official examples they use a monolith client class to handle both send and listen, so it can also do listen and send at the same time, and it can also identify if the message received is reply message of previous sent message, are we not going to implement that way?
e.g. https://github.com/apache/qpid-proton/blob/main/python/examples/client.py

[ligangty]

And one other thing is in official examples they use a monolith client class to handle both send and listen, so it can also do listen and send at the same time, and it can also identify if the message received is reply message of previous sent message, are we not going to implement that way? e.g. https://github.com/apache/qpid-proton/blob/main/python/examples/client.py

I'd prefer not to do this, because our Receiver and Sender have different handling logic, different control flow and different virtual topics to send/listen. Use separated Sender and Receiver classes can make it clearer and more readable.

[ligangty]

@shokakucarrier I'll merge this now. If you found something not correct, feel free to submit PR to fix it.