Add admin-only camera access control

[Marijn0]

This PR introduces an admin_only camera-level access control flag and enforces its use consistently across the UI, configuration storage, and backend handlers.

Cameras marked as admin-only are hidden from non-admin users in camera listings and blocked from use when accessing actions, pictures, movies, movie playback, live frames, and embedded views.
The flag is configurable via the UI, stored as @admin_only, and disabled by default for newly created cameras.

For remote cameras, the admin-only state is synchronized from the remote motionEye instance during camera listing. Remote configurations are still fetched while @admin_only is set, allowing the flag to be cleared remotely so the camera can reappear for non-admin users without requiring a local admin login. This prevents the local configuration from becoming stale when the remote admin-only state changes.

Access control is enforced on the server side: non-admin users attempting to access admin-only cameras receive HTTP 403 (access denied).

Please let me know if I missed anything 😅
This feature was also discussed in #2959.

[Marijn0]

🤔 I just noticed that when a remote motionEye camera loses its connection, I am no longer able to log in to the GUI.
I don’t think this is related to this PR, as the same behavior also occurs on the current dev branch.

[MichaIng]

Very nice, many thanks for this! I did some minor suggestions above, extending the log messages for better potential debugging and a tiny performance/load enhancement.

I'll let @copilot write tests to cover all affected APIs with and without the admin_only flag, as admin and normal user. Would be awesome if it could be (additionally) tested with two actual motionEye instances for remote camera access, instead of the testing the functions only with mocked responses. Let's see what it comes up with.

[Marijn0]

I think I have addressed all your suggestions.
One additional point I’d like to get your thoughts on is the following:

When using a remote motionEye camera and connecting to older versions of motionEye that do not provide the admin_only option, the local admin_only setting is currently always reset to False, because the field is missing from the remote configuration response.

This makes it impossible to use the admin_only option with legacy motionEye / motioneyeOS remote cameras.

Would it make sense to preserve the locally configured admin_only value when the remote configuration does not include this field, and only synchronize it when the remote instance actually supports admin_only?

I am still thinking about the best approach to achieve this, and I’m curious to hear your thoughts, thanks!

[MichaIng]

Would it make sense to preserve the locally configured admin_only value when the remote configuration does not include this field, and only synchronize it when the remote instance actually supports admin_only?

That seems to make sense to me. Let's assume, if an admin enables the admin-only flag for a remote camera (them obviously have access/credentials for), this is wanted even if the remote instance is old, to the degree it is possible, i.e. locally at least. Hence, I'd vote for always using the local value in this case.

However, as far as I can see, the response it the same whether the remote motionEye has the flag unset or does not support it at all, isn't it? So how do we know whether it is intentionally disabled on the remote or not support it? We could check the version string, of course ...

Also, if an instance sets a local camera admin-only, is it actually correct to assume that this is intended at any remote as well, and that the remote shall not be able to change this? I mean both instances might have different admins/users, different credentials etc, maybe it is good to allow the flexibility that both instances can configure access to the camera independently?

Probably this compromise:

• If a remote motionEye camera is added newly (how do we know it?) and has the admin-only flag set, use this as default locally as well.
• If the camera exists locally already, e.g. settings are changed/saved, do no sync/override the local admin-only setting.
• Hence allow local and remote admins changing this setting individually, which implies that it remains disabled locally, if either the remote or local instance did not support that flag yet.

EDIT: Copilot PR for the tests: #3247
Opened against false branch, let's see whether it is able to rebase it as I instructed, else it cannot work until this PR has been merged into our dev.
EDIT2: Took a while, it searched up and down for admin_only/adminOnly/ADMIN_ONLY/admin/only in our branches, and I thought it will fail, but finally after maybe 10-20 unsuccessful searches, it finally merged your branch into its local branch 😄:

Funny to watch. Let's see what it comes up with in the end 🙂.