### Is there an existing issue for this?

- [X] I have searched the existing issues

### Current Behavior

When using DynamoDB with global tables (v2019.11.21), I am experiencing two problems that leads me to believe something is making global tables not fully replicate:

1) When creating the table with CLI and then adding replication, I can see that the table gets replication turned on, but when listing the tables in the other region – nothing is returned. Additionally, no DynamoDbStream is created in the other region from what I can see.

2) Creating the table with terraform and replication turned on does not work, and I need to turn off replication for the table to properly instantiate. I can add replication later with CLI however, but then I get problem 1 above.

### Expected Behavior

1. When listing tables in the other region, I would expect to see a table there and be able to find a corresponding DynamoDbStream by describing the table.
2. I expect that creating a global table with v2019.11.21 using terraform would work.

### How are you starting LocalStack?

With a docker-compose file

### Steps To Reproduce

(In the examples, the default region is set to us-east-1)

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

services:
  localstack:
    image: localstack/localstack:latest
    restart: unless-stopped
    healthcheck:
      test: [ "CMD-SHELL", "awslocal dynamodb list-tables && awslocal dynamodbstreams list-streams" ]
    environment:
      - DEBUG=1
      - HOSTNAME=localstack
      - AWS_DEFAULT_REGION=us-east-1
    ports:
      - 4566:4566
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock
```

#### Client commands (e.g., AWS SDK code snippet, or sequence of "awslocal" commands) [issue 1]
1. create the table
```
awslocal dynamodb create-table \
  --table-name 'Table' \
  --attribute-definitions AttributeName=PK,AttributeType=S AttributeName=SK,AttributeType=S \
  --key-schema AttributeName=PK,KeyType=HASH AttributeName=SK,KeyType=RANGE \
  --provisioned-throughput ReadCapacityUnits=1,WriteCapacityUnits=1 \
  --stream-specification StreamEnabled=true,StreamViewType=NEW_AND_OLD_IMAGES
```
2. set up replication
```
awslocal dynamodb update-table \
  --table-name 'Table' \
  --cli-input-json \
  "{
    \"ReplicaUpdates\":
    [
      {
        \"Create\": {
          \"RegionName\": \"eu-west-1\"
        }
      }
    ]
  }"
```
3. verify replication is setup
```
awslocal dynamodb describe-table --table-name 'Table' --query 'Table.Replicas'
```
4. when listing the tables in the other region, no table is returned and I can't query for the DynamoDbStream
```
awslocal dynamodb list-tables --region eu-west-1
```

#### Client commands (e.g., AWS SDK code snippet, or sequence of "awslocal" commands) [issue 2]
1. run `terraform apply` with a simple table configuration where replica is set
```
resource "aws_dynamodb_table" "table" {
  name           = "table"
  billing_mode   = "PROVISIONED"
  read_capacity  = 1
  write_capacity = 1

  hash_key  = "PK"
  range_key = "SK"

  attribute {
    name = "PK"
    type = "S"
  }

  attribute {
    name = "SK"
    type = "S"
  }

  replica {
    region_name = "eu-west-1"
  }

  stream_enabled   = true
  stream_view_type = "NEW_AND_OLD_IMAGES"
}
```
This yields the error `Error: creating Amazon DynamoDB Table (table): replicas: waiting for replica (eu-west-1) creation: unexpected state '', wanted target 'ACTIVE'. last error: %!s(<nil>)`. When removing the replica section, it works just fine.

### Environment

```markdown
- OS: macOS Ventura 13.0
- LocalStack: latest
```


### Anything else?

I tried to look at global tables with version 2019.11.21 in AWS using the CLI and it looks to me that the replicated table would be listable/describe:able in each of the replicated regions, that's why I assumed this might be a bug of some sort.

Creating one issue describing both problems as I believe these might be related. Possibly, some part of the replication is not complete which is why 1) is happening. Additionally, 2) could potentially be a guide for finding the root cause. It seems though that items are replicated in both regions in scenario 1), even though the replica is not describe:able.

I've tried searching for similar issues and more information on whether multi region is supported at all by Localstack, and since I had a hard time finding answers, I thought it'd be best to create an issue around this!
import base64
import json
import os
import pytest
from localstack.aws.api.lambda_ import InvocationType, State
from localstack.testing.aws.lambda_utils import is_new_provider, is_old_provider
from localstack.testing.snapshots.transformer import SortingTransformer
from localstack.utils.common import short_uid
from localstack.utils.http import safe_requests
from localstack.utils.strings import to_bytes, to_str
from localstack.utils.sync import retry, wait_until
from localstack.utils.testutil import get_lambda_log_events
@pytest.mark.skipif(condition=is_new_provider(), reason="not implemented yet")
@pytest.mark.aws_validated
def test_lambda_w_dynamodb_event_filter(
    cfn_client, dynamodb_client, logs_client, deploy_cfn_template
):
    function_name = f"test-fn-{short_uid()}"
    table_name = f"ddb-tbl-{short_uid()}"
    item_to_put = {"id": {"S": "test123"}, "id2": {"S": "test42"}}
    item_to_put2 = {"id": {"S": "test123"}, "id2": {"S": "test67"}}
    deploy_cfn_template(
        template_path=os.path.join(
            os.path.dirname(__file__), "../../templates/lambda_dynamodb_filtering.yaml"
        ),
        parameters={
            "FunctionName": function_name,
            "TableName": table_name,
            "Filter": '{"eventName": ["MODIFY"]}',
        },
    )
    dynamodb_client.put_item(TableName=table_name, Item=item_to_put)
    dynamodb_client.put_item(TableName=table_name, Item=item_to_put2)
    def _assert_single_lambda_call():
        events = get_lambda_log_events(function_name, logs_client=logs_client)
        assert len(events) == 1
        msg = events[0]
        if not isinstance(msg, str):
            msg = json.dumps(msg)
        assert "MODIFY" in msg and "INSERT" not in msg
    retry(_assert_single_lambda_call, retries=30)
@pytest.mark.skip_snapshot_verify(
    paths=[
        "$..Metadata",
        "$..DriftInformation",
        "$..Type",
        "$..Message",
        "$..access-control-allow-headers",
        "$..access-control-allow-met