Use our Koji tags and repo names for our releases

This is a big change.

First, our versions are not numeric like in Fedora, it's 5.0, 5.1,... So
we need to change the way this is handled.

Also, if we're changing the way Bodhi guesses Koji tags and repo names,
then we might as well remove all the various conditions on pending
releases (we don't do that) and EPEL special casing.

It makes the patch bigger, but the overall code becomes simpler.
Unit tests: Fix for our repos/tags setup

The unit tests make a lot of assumptions that we invalidate in the
previous commit.

This ports them to our own assumptions.
Mash: Fix for our releases/repos/tags setup

Mash assumes that tags are called under the following convention:
    $release-testing
    $release-updates

So it splits them on the last '-' and takes the first part, then decides
that's what it needs.

In our case, this is problematic because the tags are named as follow:
    nb5.0-free
    nb5.0-free-testing

So splitting as it does, we end up with something wrongly inconsistent.
Write the mail template to our needs

The Fedora email templates are hardcoded... :(

So we just drop them and hardcode ours instead.
Unit tests: Fix for our mail template
Updates Policy: Disable automatic push to stable

We don't want to have an update go to stable automatically. Ever.

The stable_karma thing doesn't allow specifying a value for that (e.g
`-1`, `0` is for pushing straight-away without any need for any karma),
so let'ts just make the threshold ridiculously high, and uncheck the box
by default.
Unit tests: Fix for our "disabled" stable karma
Updates Policy: Don't enforce a minimum time in testing

Our policy is much simpler: a proventester must ack the update.

Enforcing a minimum number of days in testing just complicates the
process, and doesn't bring us any benefit. Updates will just stay in
testing until they are acked, and will be moved to stable as soon as
they are.
Updates Policy: Keep the same requirements for critpath

All updates have the same testing requirements in NBRS 5: they must be
acked by (at least) one proventester.

That's it.

Critical path is purely informative for us (granted, it's very valuable
information).
Unit tests: Fix for our policies about critpath and min days in testing
Updates Policy: All provenpackagers and releng can push to all packages

We don't use Fedora's PackageDB. Users authenticate against our
internal LDAP, but the package ACL system is set to 'dummy'.

So let's hardcode the group values we use.

And because we don't use PackageDB, I took the liberty to simplify the
API for this function, and remove useless code which was just setting up
the arguments related to PackageDB.
Unit tests: Fix for our permissions change
Updates Policy: Prevent anonymous karma

Only identified developers and QA people will be giving
karma. Ever.

We are not an open community creating a general-purpose
distribution, we are a security company creating a
specialized OS for our products.

So anonymous karma just makes no sense in our case.

Also this removes the dependency on TGCaptcha2, which is
always nice, as it's one less package I have to maintain. :)
Unit tests: Remove the captcha test

There's really nothing to test now, anonymous karma
doesn't exist any more in our Bodhi tree.
Mash: Don't update comps for now

This assumes there's an accessible Git repo to update the comps
files from, which we don't have.

We'll improve that later on.
Mash: Separate the mash locks for our releases

We have different releases for free and nonfree packages,
but we want them to share the same id_prefix.

To allow mashing them in parallel, we need to base the mash
lock on something else than the id_prefix.
Mash: Separate the repomd config for our releases

We have different releases for free and nonfree packages,
but we want them to share the same id_prefix.

To avoid confusing Mash, we need to base the repomd config
on something else that the id_prefix.
Mash: Don't try to get the pkgtags

This information comes from the PackageDB, which we haven't
deployed.
Make our metrics more accurate

Upstream hardcodes very long intervals between the metrics refreshes.

That's most likely because Fedora has so many updates coming in
constantly that it would be very expensive to refresh them so regularly.

We have **much** less updates, so we can afford to run these jobs more
frequently, which makes the metrics more accurate, or at least less
often inaccurate.