Fix bug where project name not set in user-agent

[joereuss12]

Project name, if set, will now show up in the user-agent header for requests. This PR also removes some old unused legacy code of the "payload" object (the only piece of the object still used was the project name). Also includes a unit test checking that the client properly sets this header.

[haoming29]

Running the code locally, I still get grab as the appinfo field in xrootd monitoring packet, but the client-side tests look good to me

DEBUG[2024-03-25T14:48:58Z] MonPacket: Received an appinfo packet        
DEBUG[2024-03-25T14:48:58Z] GetSIDRest inputs: http/unknown.1:32828963699019@6ee28c5df997
grab 

[joereuss12]

Running the code locally, I still get grab as the appinfo field in xrootd monitoring packet, but the client-side tests look good to me

DEBUG[2024-03-25T14:48:58Z] MonPacket: Received an appinfo packet        
DEBUG[2024-03-25T14:48:58Z] GetSIDRest inputs: http/unknown.1:32828963699019@6ee28c5df997
grab 

Are there multiple of those appinfo fields returned? When I run it I get quite a few returned to me with some being what is expected. I can play around with this more tho if that is not the case

[haoming29]

Running the code locally, I still get grab as the appinfo field in xrootd monitoring packet, but the client-side tests look good to me

DEBUG[2024-03-25T14:48:58Z] MonPacket: Received an appinfo packet        
DEBUG[2024-03-25T14:48:58Z] GetSIDRest inputs: http/unknown.1:32828963699019@6ee28c5df997
grab 

Are there multiple of those appinfo fields returned? When I run it I get quite a few returned to me with some being what is expected. I can play around with this more tho if that is not the case

There are, but the only one that seems to relate to the file transfer is the grab, others have go-http-client. Also, it's possible that I didn't get the correct mock of .job.id

[joereuss12]

Yeah, I don't think it will show up unless the project name is set correctly. You can set an env variable called _CONDOR_JOB_AD to a file or having a .job.ad file that contains ProjectName = <project name>. However, I think we should have something show if it is not set, at least with the Pelican version no matter what.

[joereuss12]

@haoming29 Give this a go now. I was seeing grab too locally but with this one line change it seems to be giving me the correct User-Agent now.

[haoming29]

The revised version gave me pelican-client/7.6.1-next project/some project name as the user agent header read by the xrootd, which should be what we expect. Give the green light here. For the comment on the localcache, feel free address it or not.

Thanks for fixing this!

[haoming29]

Yeah, I don't think it will show up unless the project name is set correctly. You can set an env variable called _CONDOR_JOB_AD to a file or having a .job.ad file that contains ProjectName = <project name>. However, I think we should have something show if it is not set, at least with the Pelican version no matter what.

I found that the catch here is that I only get a non-empty project name if the ProjectName field in the job ad is a quoted string like ProjectName = "some project name". If I simply pass something like ProjectName = NRAO-project888, pelican client won't recognize it as a valid project name and ignored it. I'm not sure the syntax of job ad file but this is something that we should be aware of.

[joereuss12]

Alright, made those suggestions as well as allowed the ProjectName to be surrounded by "" or not and still work. Just going to let the tests run just in case before I merge.