We need to change the way we access `JobDetail`-pages based on recent
namespace changes.

We need to access job-details differently when they have a namespace
due to recent namespace changes - we need to make the tests reflect
that.

There is no need to check the namespace query-param anymore with
`urlWithNamespace` but some tests still are using this. We refactor
the tests to be less clever and check the URL in a more manual approach
by explicitly defining how the URL should look like if a job belongs
to a namespace.

Recent changes changed the behavior of not adding the `@default`
-namespace - we need to adapt the tests accordingly

Default namespaced jobs don't append the `@default`-id anymore due
to recent `jobs.job#serialize` changes.

* less clever™ metaprogramming when checking for expectedURL
* clicking slices job-client-status-summary needs to change its
  behavior and not pass the namespace query-param anymore.

The new ID handling gives us this behavior for free and we don't need
to drill the namespace down through all the route-layers anymore.

This will give us 'correct' URLs for free when we only pass a `job`-model
to a `LinkTo` that links to the `jobs.job.*`-routes.

We need to adapt the test due to recent namespace changes.

When an allocation is updated, the job summary for the associated job
is also updated. CSI uses the job summary to set the expected count
for controller and node plugins. We incorrectly used the allocation's
server status instead of the job status when deciding whether to
update or remove the job from the plugins. This caused a node drain or
other terminal state for an allocation to clear the expected count for
the entire plugin.

Use the job status to guide whether to update or remove the expected
count.

The existing CSI tests for the state store incorrectly modeled the
updates we received from servers vs those we received from clients,
leading to test assertions that passed when they should not.

Rework the tests to clarify each step in the lifecycle and rename CSI state
store functions for clarity

env: update aws cpu configs

By running the tools/ec2info tool

Processing an evaluation is nearly a pure function over the state
snapshot, but we randomly shuffle the nodes. This means that
developers can't take a given state snapshot and pass an evaluation
through it and be guaranteed the same plan results.

But the evaluation ID is already random, so if we use this as the seed
for shuffling the nodes we can greatly reduce the sources of
non-determinism. Unfortunately golang map iteration uses a global
source of randomness and not a goroutine-local one, but arguably
if the scheduler behavior is impacted by this, that's a bug in the
iteration.

changelog: update changelog for DO

Co-authored-by: Luiz Aoqui <luiz@hashicorp.com>

client/fingerprint: add digitalocean fingerprinter

website: display warning in IE 11

Co-authored-by: Seth Hoenig <seth.a.hoenig@gmail.com>

If processing a specific evaluation causes the scheduler (and
therefore the entire server) to panic, that evaluation will never
get a chance to be nack'd and cleared from the state store. It will
get dequeued by another scheduler, causing that server to panic, and
so forth until all servers are in a panic loop. This prevents the
operator from intervening to remove the evaluation or update the
state.

Recover the goroutine from the top-level `Process` methods for each
scheduler so that this condition can be detected without panicking the
server process. This will lead to a loop of recovering the scheduler
goroutine until the eval can be removed or nack'd, but that's much
better than taking a downtime.

* reconciler: improved variable names and extract methods from inline logic
Co-authored-by: Tim Gross <tgross@hashicorp.com>

PR #11956 implemented a new mTLS RPC check to validate the role of the
certificate used in the request, but further testing revealed two flaws:

  1. client-only endpoints did not accept server certificates so the
     request would fail when forwarded from one server to another.
  2. the certificate was being checked after the request was forwarded,
     so the check would happen over the server certificate, not the
     actual source.

This commit checks for the desired mTLS level, where the client level
accepts both, a server or a client certificate. It also validates the
cercertificate before the request is forwarded.

Merge pull request #12002 from hashicorp/dependabot/go_modules/github.com/hashicorp/go-version-1.4.0

build(deps): bump github.com/hashicorp/go-version from 1.3.0 to 1.4.0