Better cookie handling in millennium_http_request and millennium.import.inc

I love all the new possibilities to fetch data from Millennium. However, somehow my cart mass import stopped working lately. It took quite a while to figure out the problem, but here's the explanation and a fix. This probably came up as part of #619450: Crawl or import from a URL with a list (ftlist or search result).

The problem: the mass importer couldn't find any records from my correct list. ("Not found" for all.)

There were actually many reasons for this.

First, our WebOPAC seems to need all the different cookie headers to maintain the session. So, I had to modify millennium_http_request to save all of the information below...

Set-Cookie: III_EXPT_FILE=aa10097; [...]
Set-Cookie: III_SESSION_ID=f34c3aeec88e1d1145851181c0995e47; [...]
Set-Cookie: SESSION_SCOPE=9; [...]

... not just the III_SESSION_ID part. (Haven't actually tested if ALL of those cookies are necessary, but this is what my Firefox browser uses, so probably best to do the same.) These will be concatenated thusly into the request:

Cookie: III_EXPT_FILE=aa10097; III_SESSION_ID=f34c3aeec88e1d1145851181c0995e47; SESSION_SCOPE=9;

The second problem was with the original saving of the cookie data to the db or the static cache. My WebOPAC requires a valid session *before* the first request to save into the cart. With a freshly cleared cache, there's no session, so if the first thing you try to do is mass import, it won't work. That's why I added a ping to the mass import function, just to get the cookie. This bug is hard to notice if you're using a much-used database, but it's a problem for first timers.

And finally, maybe not related to the problem, $path = "/search?///1,-1,-1,B/browse?clear_saves=1"; gives me a 404 error, I think it should be $path = "/search?//1,-1,-1,B/browse?clear_saves=1";. (One '/' removed -- try it with a WebOPAC!)

I'll send my patch right up! =)