[Web] make clientService more developer friendly

[kulmann]

Description

At the moment you can shoot yourself in the foot quite easily by destructuring the clientService (e.g. const { webdav } = useClientService(). The destructured respective client (here: webdav) will not a reactive authentication. Meaning that after a token renewal the destructured client will not have valid authentication anymore. See https://github.com/owncloud/web/pull/11068 for one of our own fallouts from this. Since destructuring objects is a quite common concept in the JS ecosystem we should avoid this pitfall.

User Stories

• As a developer, I don't want to fall into the trap of losing valid authentication, so that I don't deliver a version of my app that has failing requests after a token renewal.

Value

DX

Acceptance Criteria

One of the following:

• forbid destructuring the client service (I don't see how...)
• make sure that the destructured clients from the client service have a reactive authentication

Definition of ready

• [ ] Everybody needs to understand the value written in the user story
• [ ] Acceptance criteria have to be defined
• [ ] All dependencies of the user story need to be identified
• [ ] Feature should be seen from an end user perspective
• [ ] Story has to be estimated
• [ ] Story points need to be less than 20

Definition of done

• Functional requirements
  • [ ] Functionality described in the user story works
  • [ ] Acceptance criteria are fulfilled
• Quality
  • [ ] Code review happened
  • [ ] CI is green (that includes new and existing automated tests)
  • [ ] Critical code received unit tests by the developer
• Non-functional requirements
  • [ ] No sonar cloud issues

[AlexAndBear]

Could we use getters for singleton instances here, or would that result in the same issue ?

[dschmidt]

I guess we can make every object reactive instead of only the "top level" one