Bugzilla::CGI.pm checked in

[Bradley Baetz]

I've just checked in bug 147833, which makes us use CGI.pm for 
parsing queries/cookies/etc. I've kept backwards compat code with the 
following exceptions:

- $::FILE is gone - this was the only place where the concept differed
greatly from our stuff, and so it was easier to convert the single user
(attachment.cgi) that to get working backwards compat code. Instead, use
the CGI.pm API. See attachment.cgi for the changes.

- Previously, data in $::COOKIE was left url_quoted. This has been fixed
(because thats what CGI.pm's cookie method does, sensibly). I converted 
all the callers which cared (there was only 1, IIRC). Most users didn't 
unquote it anyway. (I'm wondering if this is somehow behind the bug where 
COLUMNLIST gets ignored every so often). This change doesn't apply to 
$::COOKIE{'Bugzilla_login'}, which the login code sets to a canonical 
value, and so it was always unquoted. ('bleh!' :) Ditto for the login 
cookie COOKIE. This is a massive mess, and will probably end up being 
sorted out when we move to User.pm objects.

Other notes:

- Using $::FORM, $::MFORM, or $::COOKIE is deprecated. Instead, at the top
of the script, do |use vars qw($cgi);|, and then use $cgi->param or
$cgi->cookie instead. (The reason for the |use vars| is that when we can
eventually drop the backwards compat code, the only change will be to add
|my $cgi = new Bugzilla::CGI()| to the top of each script, and we won't
have to s/\$::cgi/\$cgi/ everywhere)

- Note that using $cgi for header output should not yet be done. This is
because CGI.pm will always add a content-type on text/* documents if we
don't explicitly set one. This may have problems, and needs to be looked
into a bit before its enabled.

- There are no plans to use CGI.pm for output of html elements. My opinion
is that TT is much more flexable for our purposes, and that it would be
less confsuing if we don't mix the two, so its better off keeping it that
way. I'm not too fixated on that, mind you.

- I've set up CGI.pm to:
  a) not use xhtml (althogh this doesn't affect us, see the above item)
  b) use & instead of ; to separate url params, mainly for backwards compat

Bradley