[LeeroyHannigan]

What

RestoreTableToPointInTime now authorizes the item actions on the target table before dynamodb:RestoreTableToPointInTime on the source table. For a caller with no policy, the denial now names dynamodb:Scan on the target table, as on Amazon DynamoDB. On main, it names the restore action on the source table.

authz_targets in crates/server/src/authz_resource.rs returns the target's item actions first and the source's restore action last. authorize_request checks the pairs in that order, and the first denied pair is the one the denial names. The set of required actions and resources does not change, so a request that a policy allows on main is still allowed.

The admin guide's resource table and its restore note, and the v0.1.15 upgrade note, describe the new order.

This pull request does not implement point-in-time restore, which stays unsupported as on main since #335. An authorized restore still answers PointInTimeRecoveryUnavailableException, and an index SourceTableArn still answers ValidationException: Invalid Request: Table ARN is invalid. A new test pins that second answer.

Why

#446 measured both answers on the service on 22 October, for a caller with no policy and for an admin, with an index SourceTableArn. The denial on main named a different action and resource. A policy written against the service's denial therefore sees a different action and resource on ExtendDB.

Part of #446

Testing done

• restore_order_tests.rs in crates/server/src/authz_resource/ checks the order of the authorization targets and the denial for a caller with no policy. other_arn_fields_keep_the_supplied_spelling now reads the source from the last target. With main's order, all three tests fail.
• Two tests in tests/test_authz_resource_arn.py send a RestoreTableToPointInTime request with an index SourceTableArn. The first expects the denial for a caller with no policy to name dynamodb:Scan on the target. The second expects Invalid Request: Table ARN is invalid. for a caller allowed dynamodb:*. I ran the four restore tests of the file against a SQLite server built from this branch: 4 passed. With main's order restored in authz_targets, the dynamodb:Scan test fails and the other three pass. The Table ARN is invalid answer is already on main, so that test passes there too.
• cargo +1.97.0 fmt --all -- --check: clean.
• cargo +1.97.0 clippy --locked -p extenddb-server --all-targets -- -D warnings: clean.
• cargo +1.88.0 test --locked -p extenddb-server: 295 passed.

Checklist

• I have read CONTRIBUTING.md
• All tests pass (cargo test --workspace)
• Code is formatted (cargo fmt --check)
• Clippy is clean (cargo clippy -- -W clippy::pedantic)
• I have added or updated tests for new functionality
• I have updated documentation if behavior changed
• Breaking changes are noted below (if any)
• If this changes the wire protocol, Storage trait, auth model, on-disk
  format, or public CLI surface, an RFC has been accepted or is linked
  below. Otherwise, an ADR captures the decision (link below).

ADR / RFC: n/a

---

By submitting this pull request, I confirm that my contribution is made under
the terms of the Apache License 2.0 and I agree to the Developer Certificate of
Origin (DCO). See CONTRIBUTING.md for details.