refactor: remove cyclic authz dependencies

[kocubinski]

Description

Closes: #16463

This takes approach 1. from the above issue:

1. Push AcceptResponse down into sdk/types, and change Updated field type to proto.Message. Refactor usages.

---

Author Checklist

All items are required. Please add a note to the item if the item is not applicable and
please add links to any relevant follow up issues.

I have...

• included the correct type prefix in the PR title
• added ! to the type prefix if API or client breaking change
• targeted the correct branch (see PR Targeting)
• provided a link to the relevant issue or specification
• followed the guidelines for building modules
• included the necessary unit and integration tests
• added a changelog entry to CHANGELOG.md
• included comments for documenting Go code
• updated the relevant documentation or specification
• reviewed "Files changed" and left comments if necessary
• confirmed all CI checks have passed

Reviewers Checklist

All items are required. Please add a note if the item is not applicable and please add
your handle next to the items reviewed if you only reviewed selected items.

I have...

• confirmed the correct type prefix in the PR title
• confirmed ! in the type prefix if API or client breaking change
• confirmed all author checklist items have been addressed
• reviewed state machine logic
• reviewed API design and naming
• reviewed documentation is accurate
• reviewed tests and test coverage
• manually tested (if applicable)

[julienrbrt]

I think this is pushing the problem further, right? IIRC the end goal is to have modules not import the SDK anymore (right?), so moving AcceptResponse to types/authz, solves one issue but creates another one for later. I think it is as well better if the types are closer to where they are used.

Doesn't it make more sense to remove the cyclic dependencies by moving the authorization definitions to authz directly? (However, that is wayyy more breaking).

However, if we go this way, I left one comment.

[julienrbrt]

This is quite handy, if we go this way, cannot we move the interface in types/authz?
Codec (x/bank/types/codec.go) still requires the interface registration anyway, so it does not really remove the cyclic dep as of now.

[kocubinski]

Codec (x/bank/types/codec.go) still requires the interface registration anyway, so it does not really remove the cyclic dep as of now.

Oops, I meant to move those registrations to authz. Will do that now.

This is quite handy, if we go this way, cannot we move the interface in types/authz?

This is handy while writing, but obviates one of the best features of how interfaces are implemented in go's type system. A type can implement an interface's behavior without forming an explicit relationship on the package in which it is specified.

[kocubinski]

I think this is pushing the problem further, right? IIRC the end goal is to have modules not import the SDK anymore (right?)

I think so, but it's not totally clear how that will look yet, or how we'll get there. Given this I think it's good take incremental steps. I consider removing a cyclic dependency by pushing the common dependency down an incremental improvement. We could also consider moving it api?

If we do ever eventually make the transition away from gogo types then implementing an interface method on a generated proto type will not be possible, so we'll need a different design for this authz pattern. I think that will happen eventually, but given that's not in writing either, I consider this an acceptable improvement.

Doesn't it make more sense to remove the cyclic dependencies by moving the authorization definitions to authz directly?

I'm not sure what you're proposing here, the Authorization interface is already in authz.

[julienrbrt]

I'm not sure what you're proposing here, the Authorization interface is already in authz.

Yeah, never mind that, I didn't think we could just move the type registration 😅