Remove Admin Pallet

[distributedstatemachine]

Description

Currently, the admin utilities are implemented in a separate pallet called admin-utils. This separation creates unnecessary complexity and makes it less convenient to manage and maintain these administrative functions. Moving these utilities directly into the subtensor pallet would streamline the codebase and improve overall organization.

The main motivations for this change are:

1. Reduced complexity: Having admin functions within the subtensor pallet simplifies the project structure.
2. Improved maintainability: Keeping related functionality together makes it easier to update and maintain.
3. Better encapsulation: Administrative functions are closely tied to the subtensor's core functionality and should be part of the same module.

Acceptance Criteria

• All functionality currently in the admin-utils pallet is moved into the subtensor pallet.
• The admin-utils pallet is removed from the project.
• All calls to admin functions are updated to use the new location within the subtensor pallet.
• Existing tests for admin functions are migrated and continue to pass.
• Documentation is updated to reflect the new location of admin functions.

Tasks

• Identify all admin functions in the admin-utils pallet.
• Create new modules or integrate existing ones within the subtensor pallet to house the admin functions.
• Move the implementation of each admin function from admin-utils to subtensor.
• Update any imports or dependencies that reference the old admin-utils pallet.
• Migrate and adapt existing tests for admin functions to the new location.
• Remove the admin-utils pallet from the project.
• Update documentation to reflect the new structure.

Additional Considerations

• Ensure that the move doesn't break any existing functionality or permissions.
• Update any RPC calls or external interfaces that might be affected by this change.