chore(e2e): Define docker attributes to prevent forced replacement on second launch

[moduli]

This PR modifies some enos modules to define some docker container attributes to prevent the containers from being regenerated on a second launch/terraform apply.

Currently, after launching a docker-based scenario, a subsequent launch would result all of the docker containers in being regenerated, which is not expected if they were generated successfully the first time around. This is caused because of...

❯ enos scenario exec --cmd plan e2e_ui_docker builder:local

 # module.create_boundary.docker_container.boundary must be replaced
-/+ resource "docker_container" "boundary" {
      + bridge                                      = (known after apply)
      + container_logs                              = (known after apply)
      - cpu_shares                                  = 0 -> null
      - dns                                         = [] -> null
      - dns_opts                                    = [] -> null
      - dns_search                                  = [] -> null
      ~ entrypoint                                  = [
          - "docker-entrypoint.sh",
        ] -> (known after apply)
      + exit_code                                   = (known after apply)
      - group_add                                   = [] -> null
      ~ hostname                                    = "c5f40572b57f" -> (known after apply)
      ~ id                                          = "c5f40572b57f46c5238e1cffcd9c113568e4f8806efa2160aeb9b0c2159427c2" -> (known after apply)
      ~ init                                        = false -> (known after apply)
      ~ ipc_mode                                    = "private" -> (known after apply)
      ~ log_driver                                  = "json-file" -> (known after apply)
      - log_opts                                    = {} -> null
      - max_retry_count                             = 0 -> null
      - memory                                      = 0 -> null
      - memory_swap                                 = 0 -> null
        name                                        = "boundary"
      ~ network_data                                = [
          - {
              - gateway                   = "192.168.0.1"
              - global_ipv6_prefix_length = 0
              - ip_address                = "192.168.0.6"
              - ip_prefix_length          = 20
              - network_name              = "e2e_cluster"
                # (2 unchanged attributes hidden)
            },
        ] -> (known after apply)
      - network_mode                                = "bridge" -> null # forces replacement
      - privileged                                  = false -> null
      - publish_all_ports                           = false -> null
      ~ runtime                                     = "runc" -> (known after apply)
      ~ security_opts                               = [] -> (known after apply)
      ~ shm_size                                    = 64 -> (known after apply)
      + stop_signal                                 = (known after apply)
      ~ stop_timeout                                = 0 -> (known after apply)
      - storage_opts                                = {} -> null
      - sysctls                                     = {} -> null
      - tmpfs                                       = {} -> null

Note how the network_mode attribute going back to null forces a replacement. This is potentially an issue with the provider for trying to set all of these values to null, but the workaround here is to define network_mode = "bridge" in our modules to prevent this replacement from occurring.

This fixes an issue when an e2e test tries to retry. On the first run, we do a launch. If the test fails, the workflow tries to do a second launch, but it keeps failing because it the boundary docker container doesn't start up correctly. This is because the docker container was replaced/regenerated, but the other initialization steps of the module weren't executed (i.e. initializing the database).

[moduli]

Also mode this modification as the startup for this openssh container can take a little longer. Longer-term, I want to find a better solution for this, but this is the quickest way for now.