Retrieving error types from the metadata of the Substrate palette "SubtensorModule" for the btcli console (logic)

[basfroman]

I decided to split #1859 into 2 PRs:

1. Implementation of all logic (current PR)
2. Update of existing errors with the new logic (separate PR)

Also, I had to rename the subtensor.py module due to a conflict between the class name and the module name in the namespace. This will not affect users and will not impact their experience.

[thewhaleking]

Hey man, this is a massive breaking change (changing subtensor.py => subtensor_module.py). Can you elaborate on the namespace conflicts that necessitate this?

[basfroman]

Hey man, this is a massive breaking change (changing subtensor.py => subtensor_module.py). Can you elaborate on the namespace conflicts that necessitate this?

Hey man!
Thank you for your comment and attention to the changes in the pull request. I'd like to delve into the reasons that necessitated the renaming of the subtensor.py module to subtensor_module.py.

1. Namespace Conflict: The issue of namespace conflict between the subtensor class and the module itself was quite apparent. This created complications when directly importing the class from the module, which contradicts Python’s naming conventions where class names should start with a capital letter, unlike modules. Renaming the class was not considered feasible due to existing constraints in our codebase.
2. Module and Class Clarity: Changing the module name eliminates confusion and makes the import structure clearer and more obvious, enhancing code readability and reducing the likelihood of import errors.
3. Impact Analysis: Before making this change, I conducted a thorough analysis to ensure that the renaming would only affect a limited number of places in the project, allowing for easy updates. Most interactions with the subtensor class within the project occur through the project root, and these references were not affected by the module renaming.
4. Maintenance and Scalability: This change also aims to improve the scalability and maintainability of our codebase, aligning with Python best practices for package and module naming. This simplifies the project structure understanding for future developers.

I hope these explanations help clarify the rationale behind the changes. I am open to further discussion and am willing to consider any other suggestions you might have for effectively addressing this issue.

[garrett-opentensor]

lgtm