Skip write permission checks for read-only RPC calls

[grishy]

Have you read a contributing guide?

• I have read CONTRIBUTING.md
• I have searched the existing issues and didn't find any that were similar
• I have considered creating a pull request with fixes instead of a bug report and want to proceed

Current Behavior

Thank you for the project ❤️
I'm developing a lightweight server for Anytype, reimplementing RPC for self-hosting.

I've observed that user verification currently requires confirming that a user has access not only to the Space but also to individual records. This seems redundant for read-only operations RPC.

Example

For the RPC method SpaceInfo, which returns the status of a Space:

any-sync-filenode/filenode/rpchandler.go

Lines 217 to 231 in 2b1efe4

	func (r rpcHandler) SpaceInfo(ctx context.Context, req *fileproto.SpaceInfoRequest) (resp *fileproto.SpaceInfoResponse, err error) {
	st := time.Now()
	defer func() {
	r.f.metric.RequestLog(ctx,
	"file.spaceInfo",
	metric.TotalDur(time.Since(st)),
	metric.SpaceId(req.SpaceId),
	zap.Error(err),
	)
	}()
	if resp, err = r.f.SpaceInfo(ctx, req.SpaceId); err != nil {
	return
	}
	return
	}

There's a call to StoreKey that always checks permissions.CanWrite():

any-sync-filenode/filenode/filenode.go

Lines 191 to 200 in 2b1efe4

	if identity.Account() != storageKey.GroupId {
	permissions, err := fn.acl.Permissions(ctx, identity, spaceId)
	if err != nil {
	log.WarnCtx(ctx, "acl permissions error", zap.Error(err))
	return storageKey, fileprotoerr.ErrForbidden
	}
	if !permissions.CanWrite() {
	return storageKey, fileprotoerr.ErrForbidden
	}
	}

Expected Behavior

Consider verifying only that an account has access to the space without checking permissions.CanWrite() in all RPC calls. It would be beneficial to differentiate between CanRead and CanWrite permissions for all RPC operations.

Steps To Reproduce

N/A

Environment

N/A

Anything else?

No response

[grishy]

@cheggaaa @requilence is here any problem, if we will change it?