[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 #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