Staking sdk

[chenshoo]

Pull Request Description

Please include a summary of the change and which issue is fixed. Please also include relevant motivation and context. List any dependencies that are required for this change.

Fixes (link to the issue here)

Type of change

Please delete options that are not relevant.

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Chore / Documentation
• Breaking change (fix or feature that would cause existing functionality to not work as expected)

How Has This Been Tested?

Please describe the tests that you ran to verify your changes. Provide instructions so we can reproduce. Please also list any relevant details for your test configuration

• Locally tested against Fireblocks API

Checklist:

• I have performed a self-review of my own code
• I have made corresponding changes to the documentation
• Any dependent changes have been merged and published in downstream modules
• I have added corresponding labels to the PR

[YoavBZ]

After discussing this internally - new methods should be added to the FireblocksSDK class and not in a new one. We should keep the current approach of not introducing new namespaces (NCW is exceptional).
Please align this accordingly

[orgranit]

After discussing this internally - new methods should be added to the FireblocksSDK class and not in a new one. We should keep the current approach of not introducing new namespaces (NCW is exceptional). Please align this accordingly

@YoavBZ
Can you share the reasoning behind it?
fireblocks-sdk.ts is already 2000 lines long, and nameSpaces help us prevent name collisions.
For example I prefer to keep our methods name simple as sdk.staking.getChains or sdk.staking.approveProviderTermsOfService if we would be force to flatten all under the general sdk, it would have to be called sdk.getStakingChains or sdk.approveStakingProviderTermsOfService.

[aviba]

@YoavBZ We are trying to be similar as possible to they way the auto generated SDK will create our API (from we understand it will be under a separate namespace). As this is a new API and we want to make sure the migration from this SDK to new one will be streamlined as much as possible for clients.

issue was addressed