Disable appropriate features for guest.

[shubhamdhama]

This PR addresses #8385's point:

For each feature we disable, we'll want to (1) Add the decorator/backend changes and (2) hide the relevant UI for guest users.

Opened as WIP to just check I'm disabling the right features.
Testing Plan:

• Backend tests
• Manual checking of the corresponding component

WIP list of features getting disabled:

• invite: Make invite other users inaccessible to guest users. Image: emoji upload
• emoji: Make uploading new realm emoji inaccessible for guest users. Image: invite
• streams: Hide create stream UI from guest users.
• bots: Hide UI for adding new bots for guest users.

Questions:

• deactivate_bot_backend? Because guest user can't create any bot.
• Do we want an API key of a guest accessible? I guess "Yes" because API keys can still be used as "Human bots", but I guess there are various other ways a user can access API key so what should be the appropriate behavior here?
• We haven't thought about the get_members_backend function. Having normal access over this endpoint means guest user have access to information from all members of the realm. So here we can either make this to function to return users only subscribers of streams to which the guest user is subscribed or do we have plans to hide bots and users table from guest user.
• While thinking about the above we should also think about the changes in get_raw_user_data function.
• Any plan for Default streams for guest users.

[timabbott]

I think guest users should be able to deactivate bots that they own. The context here is that if a non-guest user transfers ownership of a bot to a guest user (which I can imagine supporting for a few special situations), then the guest user should be able to disable it.

I guess stream creation should be on your list.

Guest users' API keys should be available, yes. You need it for clients like zulip-terminal.

[showell]

I know this is only 5 lines of code, but I think it's worth extracting to a function, which will allow you to flatten the code a bit and add direct tests to it:

exports.can_add_emoji = function () {
    if (page_params.is_guest) {
        return false;
    }

    if (page_params.is_admin) {
        return true;
    }

    // for normal users, we depend on the setting
    return !page_params.realm_add_emoji_by_admins_only;
};

Does that make sense?

[shubhamdhama]

Yeah... I was even not sure whether to extract this or not because most of this operations are done inline in the object code of options itself. Thanks :)

[showell]

Yeah, makes sense. Most of the existing code is probably fine to leave as is, but if you see any opportunities for quick cleanup, it's nice to be able to test all these permission things directly.

[showell]

@shubhamdhama This looks great! I have one inline comment.

[shubhamdhama]

Thanks, Steve, your review reminded me of an old settings_bots change and while cleaning it, I realized that we may still want to display "Your bots" section to guest users to show the bots whose ownership is changed(Though I don't have deep knowledge in the context of bots ownership change for guest user). So I dropped the previous commit of completely hiding the "Your bots" section and just extended the cleanup code for guest users.
Also, we may need to think about hiding tips for bots or just changing the strings for guest user(currently I've made them hidden).

[timabbott]

This is great, merged, thanks @shubhamdhama!

I agree we should think about the various tips for realm_emoji / bots; it may be worth just making a list of this sort of thing to come back to in a next pass (e.g. it seems possible we want a custom tip for guest users). I think the current list is just those two.