Allow restricting access to the root LP command

[underscore11code]

Description

Currently, the root LP command (/lp, /lpv, /lpb, etc) is publicly accessible to all players, with a vague Running LuckPerms v5.4.### message should the calling player not have permission for any sub-commands. An exceedingly common FAQ in the support channels is "Is there a way to change this message" or "Is there a way to not allow users to run the command / see the tabcompletion for it"? In general, I agree, the fact that the command is exposed to everyone with no ability to block it is a problem.

Proposed Behaviour

I see a few different logical ways of resolving this issue:

1. Register a given-by-default permission with the platform for the root command: This would be the closest to the current behavior. By default the responses would be unchanged, but should a user wish to, they could set the root permission to false. In this case, the platform would handle restricting the command & completions and no permission message, allowing the admin to customize behavior as desired.

2. Register a non-default permission with the platform for the root command: Similar to the above, just restricted by default. It's worth noting this appears to be the desired behavior by a majority of admins in support channels.

3. Restrict access ourselves: Similar to 2, though we'd be handling the restriction logic ourself. Should this be the chosen option, in order to satisfy FAQ 2, the "No Permission" message should be completely customizable (i.e. MiniMessage) - many admins wish to have a cohesive user-facing message style/language, including no permission messages.

4. Leave it as is

Extra Details

No response

[DrZoddiak]

Linking this issue here since it's somewhat relevant, though there is little discussion. Notably it was marked by Luck as Not planned.
#3729

That said, I'm very partial to maintaining expected behavior, so I believe either option 1 if we're going to engage in this, or 4.

While I don't think it's a particularly valuable contribution to the overall state of the software, I do think it would follow the expected behavior of plugins in general.

If a change like 2 or 3 were to be made, I think there should be a "breaking change" notification and version bump (or during a time where there is) but again these are not favorable options.

I do like the feedback provided, it lets the user know (without checking logs or console) that the plugin is loaded, and what version is loaded, but It isn't particularly valuable in its own right. Users don't need to know what versions of the plugin I'm running or that I have that particular plugin. Though I don't believe in security through obfuscation -- I do think it helps users to have a list of commands that are actually usable.

Many of the users that I've seen come through the discord usually are worried about users stealing their plugins or obfuscating for security concerns, but as the issue I've linked above, that user simply wanted a "clean" command interface, and for that I do see value in making a change.

Overall I think solution 1 would be the most ideal in the situation we're currently in. Allowing backwards compatibility while introducing a long-sought feature in LuckPerms that would also give Luckperms the expected behavior of having permission controlled commands.

The permission shouldn't be much of an issue, I think luckperms.lp would maintain consistency in permission naming, but luckperms.base may not hurt either.