feat: allow testing.State.get_relation to accept relation objects

[james-garner-canonical]

This PR updates testing.State.get_relation to accept a relation object. The means that users can write state_out.get_relation(rel_in) instead of state_out.get_relation(rel_in.id), and if they do so, the returned type is guaranteed to match the relation type passed in (peer, subordinate, or regular) -- both statically and at runtime.

Resolves: #2243

Alternative to:

• feat: typed testing relation getters #2326
• feat: add kind argument to testing.State.get_relation + get_relations #2358

---

For context on why testing.State.get_relation only accepts int currently, see discussion on the 2024 PR where this was designed: canonical/ops-scenario#134

[tonyandrewmeyer]

I'm +1 on this, and now -1 on both the alternatives. Thanks for taking the time to work through the options.

I'm not sure that checking the (often empty) interface and endpoint adds value, but I'm not opposed to including that.

Please do update the PR description (or commit body) for merging.

[dimaqq]

Is it the case that we don't care about the interface, because realistically we infer it from charm metadata, so it can't really change?

[james-garner-canonical]

I think validating interfaces here might come back to haunt us in the future, as there are behind the scenes shenanigans involved. See other comment (relevant bit quoted below).

PS: I'm dropping validating the interface from this PR, because I'm worried that it may lead to unexpected issues in future. The documentation threatens that it will be auto-populated from the charm's metadata if not specified, but I think this only happens with State.from_context (where you don't specify anything manually). But if we ever did start auto-populating this during Context.run or similar it would be easy to get an unexpected mismatch here (manually create Relation without interface name, then query post-run State and get mismatch).