Refactor types and utils

[shrimalmadhur]

Is your feature request related to a problem? Please describe.
We need to refactor types and utils so that it's in some standard way and not create circular dependencies.

Describe the solution you'd like

• Yet to define

Describe alternatives you've considered

Additional context

[RohanShrothrium]

Can I pick this up?

[samlaf]

Can I pick this up?

By all means! Do you want to first describe the solution you're thinking of? Like break it down into how you would refactor the files etc? Otherwise, feel free to create a PR, but we might ask you to move things around.

[RohanShrothrium]

Can I pick this up?

By all means! Do you want to first describe the solution you're thinking of? Like break it down into how you would refactor the files etc? Otherwise, feel free to create a PR, but we might ask you to move things around.

@samlaf I haven't really given it a thought, but will update the issue with what I think can be done!

[RohanShrothrium]

@samlaf I went through the code.
So here are a bunch of things I think are important to refactor:

1. The util functions used for validating types should be a common file for the types module as I believe this is not going to be used anywhere apart from validating a "type".
2. There are a few unused functions in the utils itself, not sure if this has been written for future scope. Do we want to remove this? Internal functions used for utils should not start with caps and should remain internal to the module. Eg ReadFile function. But this again calls for answering the previous question, do we want to have unused functions for future scope? I believe these should be implemented when required.
3. Certain internal functions used in validation by different types should be moved to a common.go under the types module itself.

Let me know what you think about this!

[samlaf]

@RohanShrothrium

1. agree
2. agree. ReadFile is completely useless... it's literally wrapping over os.ReadFile with the same interface. Please remove it as well as any you see fit. Only one thing to be careful, it's possible some functions are already used in https://github.com/Layr-Labs/incredible-squaring-avs. I would suggest creating a vscode workspace with both repos and making sure the functions you remove/make private are not being used there.
3. sgtm! We aren't following any type of pkg directory structure like https://github.com/golang-standards/project-layout so feel free to recommend anything you think would be useful!

[RohanShrothrium]

Hi, @samlaf!
I'm just a bit preoccupied with some work and Devconnect will take this up once I am back!

[0xpanicError]

Hey @RohanShrothrium
Are you still working on this? If not then I'd like to pick it up.

[RohanShrothrium]

@0xpanicError I totally forgot about this. Will raise a PR today ser!

[RohanShrothrium]

@samlaf I refactored the code with respect to what I mentioned. I will commit this but want to add the following additionally.
There are types defined in the crypto module. I don't see any problem here per se, but there are a few types that are imported again in the types module or in other modules. I will add this to the types module. Let me know if this sounds good.