refactor(nns): Deleted ListNeurons from NNS governance.proto.

[daniel-wong-dfinity-org]

Also ListNeuronsResponse.

Motivation/Inspiration

I started working on deleting (deciding|potential)_voting_power fields from governance.proto (NNS1-3500). Some of those fields appear in NeuronInfo. I looked into that type, and it seems like we could delete it, because AFAICT, it is only used in a couple of response types, such as ListNeuronsResponse. Therefore, this indirectly helps with getting rid of *_voting_power fields in governance.proto.

We should be able to delete most request and response types from governance.proto, because we do not store those in stable memory. This shows how we would delete other request and response types. This also shows that such deletions can be fairly straightforward.

Bonus Changes

Switch rosetta from using //rs/nns/governance to //rs/nns/governance/api. This made it possible to "lock down" //rs/nns/governance, i.e. reduce its visibility. Because min visibility good.

Make aliases generated by rust_canister inherit visibility. This was needed to lock down //rs/nns/governance without blocking legitimate dependencies from elsewhere in the bazel workspace.

How to Delete Request & Response Types from governance.proto

Here is an overview of how this PR was constructed; the same steps can (very likely) be used to delete other request and response types:

1. Delete the definitions from governance.proto (and run Prost Rust code generation). Example. However, do not simply delete the comments; instead, move them to governance.did. Example.
2. Delete the conversions in rs/nns/governance/src/pb/conversions.rs. Example.
3. Run bazel build //rs/nns/governance. This will reveal all the places that need to be updated in the main lib.
4. In every file that used the types that were deleted in step 1, replace them with the analogous API types. E.g. the following will probably get you more than 90% of the way there:

   -use crate::pb::v1::{FooRequest, FooResponse};
   +use ic_nns_governance_api::pb::v1::{FooRequest, FooResponse};
   

   The reason this is pretty effective is that the definitions of the API types were simply copied from the Prost-generated type. Example.
5. Fix problems that arise from this replacement. E.g. there may cases where you need to convert from an API type "back" to a Prost-generated type, or the other way around. This is likely the most difficult step.
6. Fix canister.rs. It might well be that the only thing you need to do here is remove some .into(). Those are no longer necessary, because now, they just convert T into T. Ofc, this change is not strictly necessary, but clippy might yell at you, and in any case, it confuses humans when you do .into() even though the object is already of the desired type.
7. Fix tests. Again, we apply steps 3-5, but this time, the goal is to make tests build. Example.

The only "insight" here is that it is fairly easy to replace Prost-generated request and response types with API types. Other than that, these steps are more or less corollaries of "delete request and response types".

The examples above are all part of this similar PR.

Why Min Visibility Good

When you want to change something, you won't need to change the whole world. I.e. encapsulation, modularity, loose coupling, non-entanglement, etc. Being able to make changes in the future is extrem imperative, because change is the only constant.

This is the exact same rationale that is used to justify private ALL the things.

References

Next PR 👉

[github-actions]

If this pull request affects the behavior of any canister owned by
the Governance team, remember to update the corresponding
unreleased_changes.md file(s).

To acknowldge this reminder (and unblock the PR), dismiss this
code review by going to the bottom of the pull request page, and
supply one of the following reasons:

1. Done.

2. No canister behavior changes.

This is a refactor.

[daniel-wong-dfinity-org]

Author's diff reading guide.

[fsodre]

Ok from the Rosetta side.