It seems more expected to not just ignore the entire pasted
command but instead strip the problem characters.

Without this, typing ^A, for instance, would add that character
to the command but not change anything visually.

From this thread:
https://github.com/xtermjs/xterm.js/issues/2673#issuecomment-574897733

I learned that onData is preferable over onKey because it’s a
higher-level representation, having already translated the
meaning of the keys. I originally avoided it because it seemed
easier to use the key events, but having abstracted the ASCII
representations of keys now, it seems similar.

Now a command can be pasted, with some caveats.

* nomad/state/state_store: enforce that the volume namespace exists

* nomad/csi_endpoint_test: a couple of broken namespaces now

* nomad/csi_endpoint_test: one more test

* nomad/node_endpoint_test: use structs.DefaultNamespace

* nomad/state/state_store_test: use DefaultNamespace

[docs] Adding link to learn track

website: link to 0.11.0-beta2 release

Actually processing arrow keys would be ideal but it’s packed
with complexity that’s not worth delving into at the moment.
This explictly ignores arrow keys; without some handling, the
behaviour was to move the cursor but not actually edit things
any differently, which was much more confusing!

finalizing scaling API work

website: update Netlify redirects syntax

connect: fix bug where absent connect.proxy stanza needs default config

blocking queries on the job scaling status

In some refactoring, a bug was introduced where if the connect.proxy
stanza in a submitted job was nil, the default proxy configuration
would not be initialized with default values, effectively breaking
Connect.

      connect {
        sidecar_service {} # should work
      }

In contrast, by setting an empty proxy stanza, the config values would
be inserted correctly.

      connect {
        sidecar_service {
	  proxy {} # workaround
	}
      }

This commit restores the original behavior, where having a proxy
stanza present is not required.

The unit test for this case has also been corrected.

Co-Authored-By: Drew Bailey <2614075+drewbailey@users.noreply.github.com>

Co-Authored-By: Drew Bailey <2614075+drewbailey@users.noreply.github.com>

Co-Authored-By: Drew Bailey <2614075+drewbailey@users.noreply.github.com>

This surfaces test failures more clearly on CircleCI by adding
testem-multi-reporter to report both via the default TAP reporter
as well as an xUnit reporter whose output is stored as an artefact.

updated ScalingEvent API to record "message string,error bool" instead
of confusing "reason,error *string"

This closes #7469. Trivial thanks to localStorageProperty! 🥳

plugin: ensure plugin loader maps correct API version to type.

fix codegen for ugorji/go

When generating ugorji/go package, we should use
github.com/hashicorp/go-msgpack/codec instead.

Also fix the reference for codegen_generated

Use latest go-bindata and go-bindata-assetfs

These dep tools aren't tagged properly so shouldn't be installed with go
mod

merge changes for expose checks percheck

* batch updates of changelog items

[ci skip]

* Update CHANGELOG.md
Co-Authored-By: Jasmine Dahilig <jasmine@dahilig.com>

* add PR to changelog

* update ui changelog message

* docs: note connect expose paths configuration in changelog
Co-authored-by: Michael Schurter <mschurter@hashicorp.com>
Co-authored-by: Jasmine Dahilig <jasmine@dahilig.com>
Co-authored-by: Seth Hoenig <shoenig@hashicorp.com>

 connect: enable proxy.expose configuration

Part of #6120

Building on the support for enabling connect proxy paths in #7323, this change
adds the ability to configure the 'service.check.expose' flag on group-level
service check definitions for services that are connect-enabled. This is a slight
deviation from the "magic" that Consul provides. With Consul, the 'expose' flag
exists on the connect.proxy stanza, which will then auto-generate expose paths
for every HTTP and gRPC service check associated with that connect-enabled
service.

A first attempt at providing similar magic for Nomad's Consul Connect integration
followed that pattern exactly, as seen in #7396. However, on reviewing the PR
we realized having the `expose` flag on the proxy stanza inseperably ties together
the automatic path generation with every HTTP/gRPC defined on the service. This
makes sense in Consul's context, because a service definition is reasonably
associated with a single "task". With Nomad's group level service definitions
however, there is a reasonable expectation that a service definition is more
abstractly representative of multiple services within the task group. In this
case, one would want to define checks of that service which concretely make HTTP
or gRPC requests to different underlying tasks. Such a model is not possible
with the course `proxy.expose` flag.

Instead, we now have the flag made available within the check definitions themselves.
By making the expose feature resolute to each check, it is possible to have
some HTTP/gRPC checks which make use of the envoy exposed paths, as well as
some HTTP/gRPC checks which make use of some orthongonal port-mapping to do
checks on some other task (or even some other bound port of the same task)
within the task group.

Given this example,

group "server-group" {
  network {
    mode = "bridge"
    port "forchecks" {
      to = -1
    }
  }

  service {
    name = "myserver"
    port = 2000

    connect {
      sidecar_service {
      }
    }

    check {
      name     = "mycheck-myserver"
      type     = "http"
      port     = "forchecks"
      interval = "3s"
      timeout  = "2s"
      method   = "GET"
      path     = "/classic/responder/health"
      expose   = true
    }
  }
}

Nomad will automatically inject (via job endpoint mutator) the
extrapolated expose path configuration, i.e.

expose {
  path {
    path            = "/classic/responder/health"
    protocol        = "http"
    local_path_port = 2000
    listener_port   = "forchecks"
  }
}

Documentation is coming in #7440 (needs updating, doing next)

Modifications to the `countdash` examples in https://github.com/hashicorp/demo-consul-101/pull/6
which will make the examples in the documentation actually runnable.

Will add some e2e tests based on the above when it becomes available.