SearchVectors sets dynamodb:ReturnConsumedCapacity, which the service lists no condition keys for #743

What happens

On a SearchVectors request that carries ReturnConsumedCapacity, ExtendDB sets the dynamodb:ReturnConsumedCapacity condition key to the request's value for authorization. When the request omits the parameter, the key is absent. The code is the SearchVectors arm of single_table in crates/server/src/parameter_keys.rs.

How it can differ from DynamoDB

The AWS service authorization reference for DynamoDB lists no condition keys for the SearchVectors action, and the DynamoDB Developer Guide says fine-grained access control is not supported for the SearchVectors API. If DynamoDB sets no condition key on a SearchVectors request, two policy shapes decide differently on ExtendDB:

• An Allow of dynamodb:SearchVectors gated on StringEquals {"dynamodb:ReturnConsumedCapacity": "NONE"} grants a SearchVectors that sets ReturnConsumedCapacity to NONE on ExtendDB. On DynamoDB the condition would never match, so the statement would grant nothing.
• A Deny of dynamodb:SearchVectors gated on StringEquals over the same key refuses a matching request on ExtendDB. On DynamoDB it would refuse nothing.

To settle

Send, on DynamoDB with a session policy, a SearchVectors that sets ReturnConsumedCapacity to NONE under each of the two statements above, twice each. If the service does not evaluate the key, single_table should give SearchVectors no keys, as it gives control-plane operations.

#738 left this value as it was: it sets the condition key defaults for the item, batch and transaction operations, and SearchVectors was not measured.