Remove Authorization requirement for Space.collaboration

[ccanos]

This fixes #5158 (client) but I'm not fully sure if this is a proper fix or if it is dangerous in any way.

• I have realized that the resolver for community doesn't have @AuthorizationAgentPrivilege either.

• With this change I can request authorization without errors

{
space(ID:"eco1") {
  collaboration{
    id
    authorization{
      myPrivileges
    }
  }
}}

which is what I need, with authorization.myPrivileges I have enough.

And I have confirmed that the other fields: relations, callouts, tagsetTemplates, timeline throw an error and come set to null if I request them.

But I am concerned about that privilege CREATE_RELATION, having that permission may be a sign of another different bug.

[valentinyanakiev]

Conceptually, that is a no-go. I have investigated thoroughly and the whole need for querying collaboration on Space comes from this PR. CollaborationPrivileges are added on SpaceContext and later those privileges are used in CalloutTypeSelect. I believe that is very very wrong and probably has multiple bugs in it.

1. Collaboraiton can be on any journey, and CalloutTypeSelect can be executed on any level, as that is, essentially, where the Callout would be.
2. At the moment CalloutTypeSelect gets the permissions from the Space.
3. That will lead to a mess on Challenge and Opportunity. I believe code similar to useCalloutCreation is needed (maybe this can be refactored into a provider if it is reused in multiple spaces).
4. Then we can remove the Collaboration from the spaceProvider queries (which were never intend to, logically, have anything to do with Collaboration - Callouts on conceptual level).

So I believe this needs re-design in the approach, it's not a simple straightforward fix.

[ccanos]

Ok, understood. I'm going to extract the authorization check from useCalloutCreation and use it for this. it's a refactor but not too big. This PR can be closed then