pin_read() on Connect fails if the owner changes

[nealrichardson]

When someone leaves the company, their content on Connect, including pins, gets transferred to someone else. But this breaks any consumers of pins who specify pins::pin_read("person-who-left/pin-name"), because it `Can't find pin named 'pin-name' with owner 'person-who-left' (code).

Reading the code, it looks like pin_read("pin-name") would work, as long as the user only has access to one pin named that. IMO, we should recommend that usage, and for cases where you're concerned that there could be multiple pins with the same name, recommend (and support in rsc_content_find()) referencing the pin by GUID, which is immutable. I don't think we should recommend the username/pinname way of referencing pins because that is not a convention that Connect knows about or enforces as a way to uniquely reference content.

[juliasilge]

This would require (well, sort of) work on the Python side to add all the looking up, guessing, etc for usernames. Currently the Python package requires you to always provide the username, for both writing and reading.

See for example:
https://github.com/rstudio/pins-python/blob/8a4faf12fee92687eb4d52b14006be1508948866/pins/boards.py#L1165

cc @isabelizimm