### Is there an existing issue for this?

- [X] I have searched the existing issues

### Current Behavior

Using localstack, I uploaded an object to a s3 bucket specifying the server side encryption as `aws:kms`, an SSEKMSId, and an SSEKMSEncryption Context. I verified that the object was correctly uploaded with the property metadata:

```
awslocal --endpoint-url=http://localhost:4566/ s3api get-object --bucket attachments-development --key .attachments/9ca85a00cde7481c02ee01f2d5e06770/384d0c0a outfile.txt

{
    "AcceptRanges": "bytes",
    "LastModified": "2023-03-02T15:20:00+00:00",
    "ContentLength": 12,
    "ETag": "\"e4d7f1b4ed2e42d15898f4b27b019da4\"",
    "VersionId": "null",
    "ContentLanguage": "en-US",
    "ContentType": "text/plain",
    "ServerSideEncryption": "aws:kms",
    "Metadata": {},
    "SSEKMSKeyId": "arn:aws:kms:us-east-1:000000000000:key/89816c0d-acfc-4a76-aa18-cabc2c8e477c",
    "TagCount": 2
}
```

I then Disabled the KMS Key and verified that it was disabled:

```
awslocal --endpoint-url=http://localhost:4566/ kms describe-key --key-id arn:aws:kms:us-east-1:000000000000:key/89816c0d-acfc-4a76-aa18-cabc2c8e477c
{
    "KeyMetadata": {
        "AWSAccountId": "000000000000",
        "KeyId": "89816c0d-acfc-4a76-aa18-cabc2c8e477c",
        "Arn": "arn:aws:kms:us-east-1:000000000000:key/89816c0d-acfc-4a76-aa18-cabc2c8e477c",
        "CreationDate": "2023-03-02T10:20:00-05:00",
        "Enabled": false,
        "Description": "kms test with localstack",
        "KeyUsage": "ENCRYPT_DECRYPT",
        "KeyState": "Disabled",
        "Origin": "AWS_KMS",
        "KeyManager": "CUSTOMER",
        "CustomerMasterKeySpec": "SYMMETRIC_DEFAULT",
        "KeySpec": "SYMMETRIC_DEFAULT",
        "EncryptionAlgorithms": [
            "SYMMETRIC_DEFAULT"
        ]
    }
}
```

Then, when I tried to do a `get-object` command on the encrypted object, I expected a `DisabledException` since s3 shouldn't be able to decrypt the encrypted object with a disabled key. However, the `get-object` command completed without an error and returned the decrypted text. 

### Expected Behavior

I would expect that `put-object`, `copy-object`, and `get-object` should throw an error if they specify a SSE-KMS key that has been disabled or does not exist.

### How are you starting LocalStack?

With a docker-compose file

### Steps To Reproduce

#### How are you starting localstack (e.g., `bin/localstack` command, arguments, or `docker-compose.yml`)

docker compose -f localstack/docker-compose.dev.yml up -d
#### Client commands (e.g., AWS SDK code snippet, or sequence of "awslocal" commands)

    awslocal --endpoint-url=http://localhost:4566  s3api mb s3://mybucket
    
    awslocal --endpoint-url=http://localhost:4566  kms create-key


    awslocal --endpoint-url=http://localhost:4566  s3api put-object --bucket <BUCKET NAME> --key <Object key>  --server-side-encryption aws:kms -–ssekms-key-id <KMS ARN>  --body outfile.txt

    awslocal --endpoint-url=http://localhost:4566/ s3api get-object --bucket <Bucket name> --key <Object key> outfile.txt

(Expect that this works and specifies the object is encrypted with aws:kms)

     awslocal kms disable-key --key-id <KMS ARN>

    awslocal --endpoint-url=http://localhost:4566/ s3api get-object --bucket <Bucket name> --key <Object key> outfile.txt
(Expect that this to throw an error but it DOES NOT)


ALTERNATIVELY 
more concisely put

    awslocal --endpoint-url=http://localhost:4566  s3api mb s3://mybucket

    awslocal --endpoint-url=http://localhost:4566  s3api put-object --bucket <BUCKET NAME> --key <Object key>  --server-side-encryption aws:kms -–ssekms-key-id <KMS ARN THAT DOES NOT EXIST>  --body outfile.txt 

The above command does not throw an error when I believe that it should

### Environment

```markdown
- OS: macOS Ventura 13.1
- LocalStack: 1.1.0
```


### Anything else?

_No response_
self, context: RequestContext, bucket: BucketName, expected_bucket_owner: AccountId = None
    ) -> None:
        call_moto(context)
        self._clear_bucket_from_store(bucket)
        self._cors_handler.invalidate_cache()
    def get_bucket_location(
        self, context: RequestContext, bucket: BucketName, expected_bucket_owner: AccountId = None
    ) -> GetBucketLocationOutput:
        """
        When implementing the ASF provider, this operation is implemented because:
        - The spec defines a root element GetBucketLocationOutput containing a LocationConstraint member, where
          S3 actually just returns the LocationConstraint on the root level (only operation so far that we know of).
        - We circumvent the root level element here by patching the spec such that this operation returns a
          single "payload" (the XML body response), which causes the serializer to directly take the payload element.
        - The above "hack" causes the fix in the serializer to not be picked up here as we're passing the XML body as
          the payload, which is why we need to manually do this here by manipulating the string.
        Botocore implements this hack for parsing the response in `botocore.handlers.py#parse_get_bucket_location`
        """
        response = call_moto(context)
        location_constraint_xml = response["LocationConstraint"]
        xml_root_end = location_constraint_xml.find(">") + 1
        location_constraint_xml = (
            f"{location_constraint_xml[:xml_root_end]}\n{location_constraint_xml[xml_root_end:]}"
        )
        response["LocationConstraint"] = location_constraint_xml[:]
        return response
    @handler("ListObjects", expand=False)
    def list_objects(