masher: Find the old updateinfo files

Now that we prefix the updateinfo metadata with its hash, the Bodhi
masher must be taught to find it.

The bonus point of using a glob is that it even handles migration from
non-prefixed to prefixed file name. :)
tests: Teach the metadata tests about the new updateinfo name
tests: Add a message on the assertion error

This assertion was failing due to a syntax error in my masher/updateinfo
code.

Adding this message allowed me to find it quickly, and it could be
useful in the future.
Fix the \n issue in update notes

For some reason, as soon as an update is saved to the DB, its update
notes are modified: all \n characters are escaped.

It could come from a misconfiguration of SQLObject or PostgreSQL, or a
different version from what is deployed on the Fedora infrastructure,
etc...

I really can't figure out what the problem could be.

This commit fixes the symptom, not the root cause. But at least, it
allows us to use Bodhi in a reasonable way, until we can fix the actual
problem.
Fix the \n issue in comment texts

This is the exact same problem as in the update notes, and
I'm applying the same change to fix the symptoms.
Don't require/use CVS any more

First, this is only used to update the comps file, the other
alternative being Git.

Right now, we're not even updating our comps file, but when that
changes, I'll use Git, not CVS.

I don't want CVS to be dragged in there, so let's kill the old code.
Don't depend on fedmsg

This is all pretty much optional in Bodhi at the moment, and Bodhi is
just emitting messages anyway.

But if we don't remove it all, then we need to package fedmsg and all
its dependencies (moksha, ...), and we'll have to set up the connection
endpoint which Bodhi tries to connect to,...

That's just not worth the hassle for a few messages which we won't make
anything of anyway.

That being said, removing all traces of fedmsg leads to a pretty
extensive patch, which is really hard to merge. (I know, I tried :)

This little hack turns out to be much simpler than the two other
alternatives.

We'll revisit when other parts of the Fedora build infrastructure are
doing cool stuff with fedmsg and we want to take advantage of it.
Branding, trademark changes

Don't advertise the web app as the 'Fedora Update System', in our
deployment it is used for our own distribution, not for Fedora.

Also, we're not really a "community maintained site", so we shouldn't
say it, and we certainly shouldn't confuse people by waiving Red Hat's
responsibility on our site. (I mean, they already have none :)

There is still the problem that the Fedora logo is used, but there's not
much that can be done here (I don't want to bundle the Network Box logo
in the Bodhi package), so we'll make symlinks at %install time in the
spec file.
Give appropriate login informations

Our users will log in with their account on our SSO, not in the Fedora
Account System.
Point to the relevant internal pages
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