Wasteful clones of URLs made in various places

[heaths]

To work with Rust's borrow checker, we often have to make clones of URLs or other strings in order to capture in an Fn or FnMut e.g., async move { }. See #867 (review) for one such place and discussion.

We could wrap it in an Arc but that also might be overkill. What other options might we have to avoid cloning potentially large strings?

[antkmsft]

We could (also/instead) make emitting relative URL aware code into a codegen configurable emitter parameter... i.e. boolean pagerRelativeUrlAware, could be false by default.

Per guidelines, Azure services should always return absolute URLs:
Pager: https://github.com/microsoft/api-guidelines/blob/vNext/azure/Guidelines.md#collections-include-nextlink-for-more-results
Poller: https://github.com/microsoft/api-guidelines/blob/vNext/azure/Guidelines.md#lro-returns-operation-location

But if your service is found guilty of returning relative URLs, the SDK service team places a config file in /sdk/service/tspconfig.json, sets pagerRelativeUrlAware to true, regenerates, releases patch, and starts talking to the service team. After the service has fixed the relative link, the property can be set back to false.

[heaths]

Talking this over more with some of the other REST API architects like @johanste I doubt we'd even want them to fix their relative links - no telling how many clients this could break, especially the ones we didn't develop and could test - but I still like the idea of having teams opt into relative next links.

That said, wrapping them in an Arc - basically turning them into a ref-counted string or URL like almost all the other Azure SDK languages enjoy - may not be so terrible. It feel like a bit of an antipattern used in this way, but certainly warranted.