Resolving user information has some friction

This issue is a bit more stream-of-consciousness than usual. I'm trying to figure out who's currently using a running app and have found it to be hard to piece together the right connectapi calls.

It's helpful that get_usage_shiny() exists, but was hard to find because I was expecting to be able to call a method on app, the result of content_item() for this app.

connectapi::get_usage_shiny(rsc, app_guid, from = Sys.time() - 3600)
#> # A tibble: 8 × 5
#>   content_guid                         user_guid                      started             ended               data_version
#>   <chr>                                <chr>                          <dttm>              <dttm>                     <int>
#> 1 4e4c747c-9909-4ec2-be95-a2dc24c6d82d aef7df1a-216b-49c9-b971-2ea16… 2024-03-01 13:05:17 2024-03-01 13:07:02            1
#> 2 4e4c747c-9909-4ec2-be95-a2dc24c6d82d dece0905-6356-423d-a985-35975… 2024-03-01 13:56:55 2024-03-01 14:17:26            1
#> 3 4e4c747c-9909-4ec2-be95-a2dc24c6d82d 359c6781-7b66-48c3-b95e-f8e23… 2024-03-01 14:16:57 NA                             1
#> 4 4e4c747c-9909-4ec2-be95-a2dc24c6d82d dece0905-6356-423d-a985-35975… 2024-03-01 14:17:12 NA                             1
**```**

However, this table doesn't include human-readable user information. If you have a specific user guid and want to know more about the user, you'd need to call `get_users(limit = Inf)`, which can be expensive.

At this point, I start thinking it would be helpful to have utilities for resolving user information from `user_guid` or `username` because it's surprisingly difficult to add user information to this table, especially because `get_users()` doesn't include `user_guid`. Note that we also have to use `limit = Inf`, which can be an expensive query.

```r
get_users(rsc, limit = Inf)
#> downloading page 27 (7.7/sec) 00:00:03 
#> # A tibble: 506 × 11
#>    email     username first_name last_name user_role created_time        updated_time        active_time         confirmed
#>    <chr>     <chr>    <chr>      <chr>     <chr>     <dttm>              <dttm>              <dttm>              <lgl>    
#>  1 user@rs…  user123  User       Name      publisher 2017-08-08 15:24:32 2023-03-02 20:25:06 2018-05-09 16:58:45 TRUE   

This Connect instance has 506 users, and as far as I can tell the only way to figure out who's using my app is to call user_guid_from_username() 506 times:

user_guid_from_username(rsc, connect_users$username)
#> Error in parse_url(url) : length(url) == 1 is not TRUE

The easy way to do that is

connect_users$guid <- connect_users$username |>
  purrr::map_chr(user_guid_from_username, client = rsc)

but it also takes a minute or so and throws warnings because sometimes multiple users are found?

Then I discovered get_acl_user(content = app), which does include the user guid! But it has been deprecated in favor of get_content_permissions(app), which does not.

The fact that no human-readable user info is included in the output of get_acl_user() points again to the general need for an "add user information" function.

Start by tracing the existing get_usage_shiny(), get_users(), user_guid_from_username(), and get_content_permissions() entry points described in the issue, noting how user identifiers and pagination are handled. The issue does not name implementation files or tests; done would require an agreed utility scope, human-readable user information in the relevant results, and tests covering lookup and expensive or ambiguous queries.