Add getter for grpc fallback urls

[Nomad-Free-Talent]

No description provided.

[snoyberg]

This approach forces an allocation of a Vec, most likely unnecessarily. I see a few alternative return types:

• &Vec<Arc<String>>: most direct, loses no power versus this return type, but exposes internals of the library (the presence of the Arc). Given that we aren't provided API stability right now, I don't see a problem with that last part.
• &[Arc<String>]: very similar to the above. I've actually never figured out whether it's more idiomatic to return a &Vec or &[] from a function. (For input, it's always better to take the slice to make the API more general.)
• impl Iterator<&str>: best for hiding the internal API, doesn't add any cost, but slightly less flexible on the calling side

I slightly lean towards the first option. @psibi what do you think?

[Nomad-Free-Talent]

In case we choose the first option, there's no need to have this additional method but change the visibility of the grpc_fallback_urls method.

cosmos-rs/packages/cosmos/src/cosmos_builder.rs

Lines 123 to 125 in 207c67a

	pub(crate) fn grpc_fallback_urls(&self) -> &Vec<Arc<String>> {
	&self.grpc_fallback_urls
	}

What do you think @snoyberg ?

[snoyberg]

It's definitely a true statement. However, the advantage of keeping the field private is it gives more flexibility in the future to update the API. But given my other comments about not providing API compatibility, it's not strictly necessary. I kept it that way up until now because it was easy enough to provide the getter/setter approach. I'm not convinced it's worth it, so certainly open to changing.

[Nomad-Free-Talent]

In that case I'm gonna change the visibility of grpc_fallback_urls method and remove the current change.