Project users can set template permissions at upload but cannot change them afterwards

Start in TemplateManagerImpl.updateTemplateOrIsoPermissions() and compare its project-owner permission check with TemplateAdapterBase.prepare(). Review the isextractable API description and existing permission tests or callers before deciding whether project members or only Project Admins should update project-owned templates. Done means the upload and update paths consistently permit the intended project users without weakening domain or root-admin controls.

problem

A project user can set ispublic and isextractable when registering a template into a project,
but cannot change either one afterwards. Not even the Project Admin can. Only a domain or root
admin can, so a project cannot manage the permissions of its own templates.

updateTemplatePermissions fails with:

Unable to grant permission to Account <name> as it is neither admin nor owner or the Template

from TemplateManagerImpl.updateTemplateOrIsoPermissions():

//Only admin or owner of the template should be able to change its permissions
if (caller.getId() != ownerId && !isAdmin) {
    throw new InvalidParameterValueException("Unable to grant permission to Account " + caller.getAccountName() + " as it is neither admin nor owner or the Template");
}

caller is always the human user's own account, while ownerId for a project template is the
project account, so the two can never be equal for a project member and every non-admin caller is
rejected.

Registration applies no such restriction: in TemplateAdapterBase.prepare() isextractable is
taken from the caller with no privilege check, and ispublic is gated only by
allow.public.user.templates.

This is not an escalation issue, an admin can revoke the flags, and the user could already set
them at upload. It is the inconsistency between the two paths that needs fixing.

versions

CloudStack: reported on 4.20.3.0; the same code is in 4.20.3.1, 4.21.0.0 and current main
(TemplateManagerImpl line 1632 on 4.20.3.0, 1565 on 4.21.0.0, 1831 on main). Not a regression.

Hypervisor: reported on VMware; the code path is hypervisor-independent.

Affects templates and ISOs alike.

The steps to reproduce the bug

1. Create a project and add a normal user to it as Project Admin.

2. As that user, register a template into the project with isextractable=true and
   ispublic=true. Both are accepted.

3. As the same user, try to change either flag:

   update templatepermissions id= isextractable=false

   Expected: succeeds — the same user set the flag two steps ago.

   Actual:

   Unable to grant permission to Account as it is neither admin nor owner or the Template

4. The same call as a root admin succeeds.

The UI behaves identically: the flags are settable in the upload dialog and rejected in template
settings afterwards.

What to do about it?

Make the two paths consistent. The natural fix is to let a project administrator act as the owner
for this check, so permissions on project-owned templates can be changed by the project that owns
them. Whether that should be any project member or only the Project Admin is worth stating
explicitly in the fix.

Useful starting point: the method already has a branch for this case a few lines earlier —

if (owner.getType() == Account.Type.PROJECT) {
    // if it is a project owned template/iso, the user must at least have access to be allowed to share it.
    _accountMgr.checkAccess(user, template);
}

but checkAccess can only reject, not grant, so callers who pass it still hit the owner/admin
throw below.

Also worth reconciling: the isextractable API description says "Can be set only by root admin",
which matches the update path but not the registration path.