Archive req

Hi Elvin and Andreas,

I've just added a very simple "piggy backing" solution for passing an CTA archive request ID from the FST to the MGM via the CLOSEW workflow notification message. We require CTA files in the EOS namespace to have their corresponding archive request ID with them so that we can delete the archive request when we delete the file. This branch fixes a problem that we are experiencing with the ALICE probe which currently creates files in our eosctaalicepps instances and then deletes them as a probe should do. We do NOT delete the corresponding archive requests at the moment and this then leads to us physically mount tapes and try to archive non-existent disk files to them. Very, very bad for the tape drive hardware and tapes.

The full story as a scenario:

1. A user finishes writing a file to disk.
2. The _close() method of the FST is called.
3. FST _close() calls QueueForArchiving() and gets back the CTA object store ID of the archive request. I simply call it archive_req_id in the code.
4. The FST "piggy backs" the archive_req_id on the back of the CLOSEW workflow notification message to the MGM. The opaque name value pair is mgm.archive_req_id=XXXX.
5. The MGM HandleProtoMethodCloseEvent()' method receives the archive_req_id`.
6. The MGM sets the sys.cta.archive.objectstore.id extended attribute of the file being archived to the value of archive_req_id .
7. The user eventually deletes their file.
8. The MGM HandleProtoMethodCloseEvent() method is called.
9. The MGM HandleProtoMethodCloseEvent() method sends all extended attributes starting with sys.cta to the CTA frontend in the request to delete the file.

Each file only has one CLOSEW event in its life so I am not deleting the sys.cta.archive.objectstore.id extended attribute for the moment. It stays with its file forever. If a very old file is deleted then the deletion of its long ago completed archive request is a no-op.