GetByAddr and smaller metadata queries.

[SpicyLemon]

Description

closes: #1443

This PR:

1. Adds an include_request flag to appropriate metadata queries. The request is only included in the response if set to true. This info was previously always included, so this is a breaking change.
2. Add an exclude_id_info flag to appropriate metadata queries. If set to true, the *_id_info fields in the response will not be populated.
3. Create a GetByAddr endpoint that takes in one or more metadata addresses and returns all the requested items. The query metadata get command has been overhauled to utilize this query instead of each individual type query.

---

Before we can merge this PR, please make sure that all the following items have been
checked off. If any of the checklist items are not applicable, please leave them but
write a little note why.

• Targeted PR against correct branch (see CONTRIBUTING.md)
• Linked to Github issue with discussion and accepted design OR link to spec that describes this work.
• Wrote unit and integration tests
• Updated relevant documentation (docs/) or specification (x/<module>/spec/)
• Added relevant godoc comments.
• Added a relevant changelog entry to the Unreleased section in CHANGELOG.md
• Re-reviewed Files changed in the Github PR explorer
• Review Codecov Report in the comment section below once CI passes

[codecov]

Codecov Report

Merging #1614 (de8da4a) into main (7835092) will increase coverage by 0.21%.
Report is 1 commits behind head on main.
The diff coverage is 64.75%.

❗ Current head de8da4a differs from pull request most recent head 7238001. Consider uploading reports for the commit 7238001 to get more accurate results

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #1614      +/-   ##
==========================================
+ Coverage   63.61%   63.83%   +0.21%     
==========================================
  Files         223      223              
  Lines       28493    28599     +106     
==========================================
+ Hits        18127    18256     +129     
+ Misses       9179     9152      -27     
- Partials     1187     1191       +4     

Files Changed	Coverage Δ
x/metadata/keeper/query_server.go	29.94% <39.78%> (+1.41%)	⬆️
x/metadata/client/cli/query.go	80.80% <95.37%> (-0.80%)	⬇️
x/metadata/types/address.go	88.64% <100.00%> (+2.05%)	⬆️
x/metadata/types/query.go	100.00% <100.00%> (+100.00%)	⬆️

... and 2 files with indirect coverage changes

[iramiller]

seems like a pretty elegant solution ... I do wonder if this should be "exclude_extra_info" since the default for proto is null/zero so in this case the default behavior would be the existing one and the opt-in would be the streamlined results? This would give smart contract authors the option of streamlining the results if they are able but would keep existing workflows working without changes...

[SpicyLemon]

seems like a pretty elegant solution ... I do wonder if this should be "exclude_extra_info" since the default for proto is null/zero so in this case the default behavior would be the existing one and the opt-in would be the streamlined results? This would give smart contract authors the option of streamlining the results if they are able but would keep existing workflows working without changes...

I'm assuming we don't have any smart contracts dealing with metadata yet since most of that stuff is missing from the x/metadata/wasm directory. But this would break anything else that runs the queries and expects the _id_info to be there, which might not be as insignificant as I originally thought.

I primarily wanted to, by default, shrink the size of the responses. I also wanted to stick with the include_ pattern since there are several other fields in the queries that use include_, but none yet for exclude_.

I do have an entry under Client Breaking in the changelog about it. I'm not quite sure how we'd go about getting a sense of how breaking that is, though. Anything using the _id_info fields would break immediately at upgrade. If there's enough stuff already using them, though, it's probably best to switch to exclude_.

The more I think about it, though, the more I think you're right. I'll switch it to exclude_id_info.