[CLN] Fix Port Parameter Inconsistency in HttpClient (String to Integer)

[iw4p]

Description of changes

Summarize the changes made by this PR.

• Refactored Port Parameter Handling: Changed the port parameter in the HttpClient class to accept an integer instead of a string. This applies to both the Python code and the related documentation.
  • Before: port="8000" (string)
  • After: port=8000 (integer)
• Docstring Updates: Updated the docstrings in init.py to reflect the new default port value as an integer (8000 instead of "8000").
• Documentation Fixes: Corrected the documentation in client.md to reflect the updated data type for the port parameter, ensuring consistency with the code changes.

Motivation
I was interested in your project and started reading through the source code with the intention of running it and potentially contributing. While setting up the environment, I noticed an inconsistency: the default port was defined as a string ("8000") in some places, while the interface expected it as an integer. I thought this would be a good starting point for my contributions, addressing a minor but important issue to improve code consistency and reliability.

Test plan

How are these changes tested?

• Tests pass locally with pytest for python, yarn test for js, cargo test for rust

Documentation Changes

Are all docstrings for user-facing APIs updated if required? Do we need to make documentation changes in the docs repository?

• Docstrings Updated: Yes, all relevant docstrings in init.py have been updated to reflect the changes to the port parameter.
• External Documentation: Yes, updates were made to the client.md file to align with the code changes.
• Docs Repository Update Needed: No additional changes are required in the docs repository as the in-repo documentation has been updated accordingly.

[github-actions]

Reviewer Checklist

Please leverage this checklist to ensure your code review is thorough before approving

Testing, Bugs, Errors, Logs, Documentation

• Can you think of any use case in which the code does not behave as intended? Have they been tested?
• Can you think of any inputs or external events that could break the code? Is user input validated and safe? Have they been tested?
• If appropriate, are there adequate property based tests?
• If appropriate, are there adequate unit tests?
• Should any logging, debugging, tracing information be added or removed?
• Are error messages user-friendly?
• Have all documentation changes needed been made?
• Have all non-obvious changes been commented?

System Compatibility

• Are there any potential impacts on other parts of the system or backward compatibility?
• Does this change intersect with any items on our roadmap, and if so, is there a plan for fitting them together?

Quality

• Is this code of a unexpectedly high quality (Readability, Modularity, Intuitiveness)

[tazarov]

@iw4p, thank you for this. LGTM.

[iw4p]

Thank you!