Additional fixes for checkRoleEscalation - #14433

Description

This PR extends the fixes introduced in PR #12973 to address the following issues (reported by @RosiKyu):

1. Revoking a permission does not take effect until the cache expires

Only happens when dynamic.apichecker.cache.period is greater than 0. The default is 0, so default installations are not affected.

After a permission is revoked from a role, account creation carries on using the remembered copy. A restricted Domain Admin can create an account that still has the revoked permission, for as long as the cache period lasts. The window is temporary but the account created in it is permanent, so this reopens #5781 for that period.

Steps to reproduce, with cache.period=300 and the management server restarted so nothing is remembered yet:

• Grant createServiceOffering to the restricted user's role (a copy of Domain Admin with that one rule denied)
• Check in the database that the rule reads ALLOW
• As that user, create an account with the default Domain Admin role. This is allowed at this point, and it is the call that puts the permission into the cache
• Revoke createServiceOffering from the restricted user's role
• Check in the database that the rule now reads DENY
• Immediately create another account with the default Domain Admin role

Step 6 should be refused with Escalated APIs: [createServiceOffering]. (It succeeds instead.)

Steps 3 to 6 have to be done within the cache period, counted from step 3, because step 3 is what puts the permission into memory. If that time runs out in between, the database is read again correctly and the problem does not show.

2. A long list of escalated APIs makes the API return HTTP 500 with an empty response

Steps to reproduce, no special configuration needed:

• Create a Domain Admin role with only a few rules allowed (listApis, listAccounts, listDomains, createAccount, createUser, listUsers, listConfigurations). An account on that role can see about 140 APIs.
• Create an account with that role and generate API keys for it.
• As that user, run createAccount with a much more privileged role. Using the default Domain Admin role gives 326 escalated APIs and returns a proper error. Using a role with a * ALLOW rule gives 786 and returns 500 with an empty response.

cmk shows the failing case as:

(tpr_minimal) 🐱 > create account accounttype=2 username=tc-chk-c password=Password123456 firstname=T lastname=T email=c@test.local domainid=2a43e16e-f8b6-4a93-ba87-74ed1a5ecd9f roleid=5c7e8978-d79c-43f8-b2a2-5201e7192d08
🙈 Error: failed to decode response

Types of changes

• Breaking change (fix or feature that would cause existing functionality to change)
• New feature (non-breaking change which adds functionality)
• Bug fix (non-breaking change which fixes an issue)
• Enhancement (improves an existing feature and functionality)
• Cleanup (Code refactoring and cleanup, that may add test cases)
• Build/CI
• Test (unit or integration test code)

Feature/Enhancement Scale or Bug Severity

Feature/Enhancement Scale

• Major
• Minor

Bug Severity

• BLOCKER
• Critical
• Major
• Minor
• Trivial

Screenshots (if appropriate):

How Has This Been Tested?

How did you try to break this feature and the system with this change?