Allow filtering view service balance queries by asset

[hdevalence]

Is your feature request related to a problem? Please describe.

Currently, the only way to query balances is the BalanceByAddress RPC, which has one argument, the address. It would be convenient if it could filter the returned balances by asset ID. In particular, now that the AssetId proto structure allows alternate encodings, this would allow an RPC user to query balances using a base denom string.

We may also want to re-examine the RPC. It's BalanceByAddress, but addresses aren't a unit of accounting, accounts are. Also, a user might want to request the total balance across all accounts.

Describe the solution you'd like

Change the RPC to rpc Balances(BalancesRequest) returns (stream BalancesResponse).

Change BalanceByAddressRequest to

message BalancesRequest {
  // If present, filter balances to only include the account specified by the `AddressIndex`.
  core.crypto.v1alpha1.AddressIndex account_filter = 1;
  // If present, filter balances to only include the specified asset ID.
  core.crypto.v1alpha1.AssetId asset_id_filter = 2;
}

Change BalanceByAddressResponse to

message BalancesResponse {
  penumbra.core.crypto.v1alpha1.AddressIndex account = 1; 
  penumbra.core.crypto.v1alpha1.Value balance = 2;
}

Update the Rust view server implementation to reflect these changes. For now, I think it's fine for the Rust view server to return tonic::Status::unimplemented if account_filter is unset, to minimize changes to the existing code; if anyone ever complains, we'll know that someone wants to request multiple accounts simultaneously.

Additional context
This unblocks work on InterchainTest, by making it easier to write balance tests without having to build asset ID lookup tables.

[conorsch]

@aubrika Can you comment on feasibility here? It may be too late to get this into 56, but sounds like it'd unblock active work for the SL when it lands.

[aubrika]

Oh I think we can make the RPC changes for 56 if the service just needs to return unimplemented for now, and implementing the filter logic shouldn't be difficult either.

[conorsch]

Tremendous news! Thanks for tackling it, I'll me meeting with the SL folks tomorrow and keep them updated on our expected timeline.

[conorsch]

Discussed this approach with SL again today. It seems critical to support that we support passing in human-readable denom strings as args to the view.TransactionPlannerRequest method. Drilling down from that interface, ultimately it's crypto.Value that must support the optional denom string: https://buf.build/penumbra-zone/penumbra/docs/38a482841770460486cce22366c7f31d:penumbra.core.crypto.v1alpha1#penumbra.core.crypto.v1alpha1.Value

At a high level, we cannot expect external devs to know asset_ids. We can expect them to know human-readable denom strings, such as "upenumbra", so we should support the latter in our RPC methods. Or at least, provide a method to convert one to the other.

[hdevalence]

I don't think we need to change the Value struct, since the AssetId already has an alt encoding?

[conorsch]

That's helpful, thanks. I think you're right: AssetId is the only place we need the flexibility, and that should cover us everywhere. Unfortunately we can't leverage the view.* protos in interchaintest right now, due to strangelove-ventures/interchaintest#658, but will tackle that next.