Verify potential concurrency issue of repository calls within application services

[Whathecode]

There might be bugs when multiple repo calls happen within single application service calls (which are expected to be single transactions).

Should we include some notion of repository transaction management within application service hosts?

[Whathecode]

Should all RPC and event handlers be idempotent by convention?

[Whathecode]

Potential issues:

• ParticipationServiceHost.getActiveParticipationInvitations calls both getParticipationInvitations and getParticipantGroupList on ParticipationRepository.
• ProtocolServiceHost.updateParticipantDataConfiguration calls both getByOrThrow and getVersionHistoryFor on StudyProtocolRepository.

For both of these, the repo can't become inconsistent, but the returned value may be, or the request could fail possibly. This is less critical than if there would have been two update calls, which could result in inconsistent data being stored in the repo.

Therefore, I will keep this issue open so we are aware about these two specific instances, but I will remove it from the 1.0 milestone. These can be patched and wouldn't result in API changes.

P.s. there are also calls to dependent services, but this is a different issue than this one: #295

[Whathecode]

At the time of writing, there are no application service calls which contain two update calls. With the fix of #398, out-of-date repo updates can now also be handled by implementing infrastructures.

The potential reported issues above are the only remaining issues. To handle this, a unit of work pattern will need to be implemented for repos: #417