Length 8 to 100, require 1 letter and 1 number.

This was failing on clean builds that need the id and url to match

Also, updated common server_utils so it do not need to be run on RHEL distributions

It looks like this version disappeared from the downloads page within
the past few weeks. I successfully ran this play less than a month ago,
but it started failing a week or two ago, due to the 404 upon download.

I'm admittedly a bit confused as to why there appears to be at least 3
different minor versions of jenkins in use [1][2][3] (plus a major bump
on the build server?! [4]), so I simply cribbed the version used by the
`tools_jenkins` role.

References:
- [1] jenkins_version: "1.638"
- [2] jenkins_tools_version: "1.651.3"
- [3] jenkins_admin_version: "1.658"
- [4] build_jenkins_version: jenkins_2.60.3

We can just use whatever version comes in with the venv setup safely

XQueue really doesn't make things like graphviz graphs, or use apparmor
(that's done in xserver or xqwatcher I believe)

While we'll eventually switch back, having unused templates around is
confusing.

Other code removed in 8f16fd28

* Updating analytics jenkins role to work again, and to be more consistent with current codebase patterns

* Updating analytics jenkins role to work again, and to be more consistent with current codebase patterns. Moved jenkins.j2 to the directory with other j2 templates

It now throws an error from Django if you pass in the unused parameter.

* Add credentials-binding plugin to analytics jenkins

* Remove custom jenkins_plugin that no longer exists

The asset compilation scripts edxapp-update-assets-lms and
edxapp-update-assets-cms duplicate a lot of work between them. Running
webpack twice also seems to cause an intermittent error where the
second build results in a different bundle hash than the first.

It is possible to run "paver update_assets" without specifying "lms" or
"cms", in which case it just compiles it all at the same time. This
removes the duplicate invocations of webpack and should speed the build
overall.

Much of our deployment infrastructure relies on having the settings and
path controlled from the environment file.  We don't have a good
way yet to define the CONFIG file since there is an auth and an env.
There's a later ticket for that.

Right now, it would run unless you are skip-tags'ing it (which is sort
of what we do in docker builds) or if the image has access to a database
(which is what happens during production builds).  It should instead be
explicitly requested.  I would remove it entirely, but we really want it
to run during sandbox builds, which use the ansible role.