Permission based view on server settings

[Dyhr]

Summary

The server settings view was getting destroyed when you're not an admin and was obviously not readded after the permission is automatically added, leaving the whole panel empty on the first run of the game in the editor.
To fix this, rather than destroying the object we're gracefully handling the lack of permissions with a separate view that just says permission denied. The code for the button now checks permissions too for completeness sake.

The new behaviour that enables or disables objects based on permission is intended for UI use and simply has a list of permissions and their associated objects. All matching permission's objects are enabled, the default is disabled. If no permissions match, the default is enabled.

PR checklist

• The game builds properly without errors.

• No unrelated changes are present.

• No "trash" files are committed.

• Relevant code is documented.

• Update the related GitBook document, or create a new one if needed.

Pictures/Videos

Testing

Changes

• Game.unity has removed the DisableIfNotAdmin object as it's no longer used, along with updating whatever UI references are relevant
• The lobby canvas has been updated with separate panels for admin and default server settings
• Added PermissionBasedView which enables or disables objects based on the local user permission

Related issues/PRs

[iamteapot422]

Add summary comments

[iamteapot422]

I think having one role and one view per PermissionBasedView component would be more foolproof and comprehensible later. For example, PermissionBasedView component on (administrator) would enable it only when permission>=Administrator; PermissionBasedView component on (default) would enable it only when permission<Administrator. This way there is less interaction between objects and we won't need to research context to find what exactly disables/enables the object we are focused on in the future. Or at least we could have one role and a list of default and role views per component.