Shift role initialization from accounts to settings

[refs]

Description

Service initialization shouldn't block. When the accounts service starts, it notifies the settings service of a set of default roles and permissions, this piece is essential for the accounts to work but that by no means implies that its logic has to live within its business logic, since the storage layer resides in the settings service.

We want to invert the responsibility.

Changelog

Bugfix: Fix accounts initialization

Originally the accounts service relies on both the `settings` and `storage-metadata` to be up and running at the moment it starts. This is an antipattern as it will cause the entire service to panic if the dependants are not present.

We inverted this dependency and moved the default initialization data (i.e: creating roles, permissions, settings bundles) and instead of notifying the settings service that the account has to provide with such options, the settings is instead initialized with the options the accounts rely on. Essentially saving bandwith as there is no longer a gRPC call to the settings service.

For the `storage-metadata` a retry mechanism was added that retries by default 20 times to fetch the `com.owncloud.storage.metadata` from the service registry every `500` miliseconds. If this retry expires the accounts panics, as its dependency on the `storage-metadata` service cannot be resolved.

https://github.com/owncloud/ocis/pull/1696

[update-docs]

Thanks for opening this pull request! The maintainers of this repository would appreciate it if you would create a changelog item based on your changes.

[butonic]

We should document the protocol change to vanilla grpc and add the circuit breaker to the changelog.

I am also not sure the settings service should have the default roles hardcoded. But changing that is a different topic.

[refs]

I am also not sure the settings service should have the default roles hardcoded. But changing that is a different topic.

Agree, the default data has to live somewhere, since we don't do storage, what would be the best candidate in your eyes? Since the settings service is responsible to roles, permissions and settings, it only makes sense that the required minimum data to startup and do minimal operations stays inside the service boundary. How it was before, the accounts NEEDED the roles and permissions to work, and that is assuming too much. Services should be self contained.

[sonarqubecloud]

Please retry analysis of this Pull-Request directly on SonarCloud.