BUG: ArrowStringArray.copy
- [ ] closes #xxxx
- [ ] tests added / passed
- [ ] Ensure all linting tests pass, see [here](https://pandas.pydata.org/pandas-docs/dev/development/contributing_codebase.html#pre-commit) for how to run them
- [ ] whatsnew entry

Several tests currently fail bc 1) the motivating ArrowStringArray behavior is not working and 2) need a mechanism to let EAs tell tm.shares_memory what to do (maybe make it a classmethod like we do for assert_foo_equal?)

@jorisvandenbossche could use some input on how to actually get a copy here
> I don't think this change is needed (in any case not by using a slow take). A shallow copy should be sufficient (you can't mutate the arrow array).

Makes sense, thanks.  I'll revert that change and flesh out the docstring to explain this to Future Me.

> (in any case not by using a slow take)

Out of curiosity, what would a better implementation use?

> Also for a normal StringArray, we essentially make a shallow copy (we don't copy the actual string objects).

We do make a copy of the array holding the strings though right?  So `arr.copy()[0] = "foobar"` doesn't change `arr[0]` im pretty sure.  May need a "degrees of shallowness" lexicon if this comes up frequently. > Out of curiosity, what would a better implementation use?

Pyarrow doesn't provide any functionality to do this at the moment (you also don't generally need this, there is a related issue about this at https://issues.apache.org/jira/browse/ARROW-14982)

> We do make a copy of the array holding the strings though right?

Yes, I mentioned above: One thing we could do is also make a shallow copy of the underlying array itself (eg by taking a slice from start to end). 
(but note that this still is not a "copy" in the pandas sense, it will still point to the same buffers, so the `shares_memory` will still indicate it didn't actually copy anything)
