Dynamic federator remotes

[fisx]

https://wearezeta.atlassian.net/browse/FS-1115

internal docs:

http://localhost:8082/api-internal/swagger-ui/brig/

docs for devs:

(slightly outdated) docs for operators:

Checklist

• Add a new entry in an appropriate subdirectory of changelog.d
• Read and follow the PR guidelines

TODO

• double-check what our default search policy in (a) the case where we allow all domains and a new one is not listed, and (b) the case where we have an allow entry in the cassandra table, but it has no search policy. also check if we're getting it right in the docs. (i think (a) should be no_search and (b) should be no NULL allowed in database field, just pick something, it's not that hard.) maybe write integration tests?
• log 'F' are sometimes too harsh. 'I' or 'D' would do. eg., for "couldn't pull data from brig yet, retrying".
• yeah, galley integration tests where hanging for me as well, but the last 3 rounds everything went green ok.
• Dynamic federator remotes #3260 (review)

[battermann]

This is just a comment, and there is no need to take action. Just to document what I have tested.

setFederationStrategy in brig.integration.yaml should be set to allowAll which matches the old setting in federator before this PR.

If we change setFederationStrategy to allowDynamic and add example.com and b.example.com to the allow list, a couple of integration tests fail. The reason is that some tests that expect 400 federation-denied now get 422 invalid-domain. Since the exact same thing happens when changing the old setting in federator to allowDomains this is expected and absolutely fine.

The errors are not listed in the specific endpoint descriptions in the swagger, but they are all listed as federation errors in the overall API descriptions. So clients should be aware and prepared to handle them all.

All looking good 👍

[battermann]

The old setting for cloud was:

    federationStrategy:
      allowedDomains: []

Should we set it to allowDynamic with an empty list here, too, to exactly match the old behavior?

[fisx]

the two are different in behavior if the database table is non-empty. so i'd argue allowNone is keeping behavior as unchanged as can be.

[battermann]

Add details or remove?

[fisx]

fair point. but i'm not going to spend another day beating concourse for this change :-P

[fisx]

ready to merge!