[JENKINS-72558] Add back the readObject method to TapPublisher, mistakenly removed in 2.4

[kinow]

Testing done

### Submitter checklist
- [x] Make sure you are opening from a **topic/feature/bugfix branch** (right side) and not your main branch!
- [x] Ensure that the pull request title represents the desired changelog entry
- [x] Please describe what you did
- [x] Link to relevant issues in GitHub or Jira
- [ ] Link to relevant pull requests, esp. upstream and downstream changes
- [ ] Ensure you have provided tests - that demonstrates feature works or fixes the issue

[NotMyFault]

Hey @kinow,

apologizes for the disruption. Would you accept @judovana as another maintainer of this plugin? They filed an adoption request, but evidently, this plugin is active and not up for adoption :)

I would appreciate an answer, thanks!

[kinow]

Hey @kinow,

apologizes for the disruption. Would you accept @judovana as another maintainer of this plugin? They filed an adoption request, but evidently, this plugin is active and not up for adoption :)

I would appreciate an answer, thanks!

Hi @NotMyFault I think I replied in another issue (in another org?). The answer was no based that they requested that in order to get their pull request merged. I replied to the pull request (this one, I believe, #29) with a feedback on what I expected to have so that we could merge it.

There was a reply near x-mas break, but I saw that we would still need to discuss more about it as they had a different opinion on some points (which is fair, and they even included screenshots and tried to explain better): #29 (comment)

Now, my reason for saying no there (and I am fine saying that here too), is that @judovana did not send other meaningful contributions to the plug-in, nor assisted with issues, and I am not sure if they know the plug-in API, or have other experience with Jenkins plug-ins.

Alas the tap-plugin code is quite dated, and I would prefer to add other contributors who are aware of Jenkins API and release process (which I am not following very closely to be honest) and with whom communication is easier (see the other issue where you can see that there were communication issues where there was a demand for open source volunteer work to be done asap, with the messages were borderline rude, but I believe it's due to both of us living in other cultures or speaking other languages).

This is the second time this is requested, and I will maintain that I do not support they to be added as contributor for now. No objection if in the future that happens 👍

I will keep working on bugs first, and then will add his feature when we have agreed on how it should work, in an accessible and simple way for users (and also easier to maintain), and perhaps some basic tests (which I have to check if these were added -- otherwise I can help with that).

@judovana may file other requests to become a maintainer, but I don't think that's a good way to get their issues merged or to call attention to old issues (go through scriptler, git plugin and you will find lots of older PR's and issues -- that happens).

Cheers

[kinow]

(There's also a security XSS issue that needs to be fixed, that's way higher priority than PR's for new feature -- if someone were to help with those, with updating the plug-in API, etc., and communicating well, then I would be the one pushing for that person to become a co-maintainer!)

[NotMyFault]

Hey,

Thanks for the swift and reasonable response. Given you objected to the adoption request, I will go ahead and close their issue.

[kinow]

Confirmed in JIRA by Michael Prokop that this apparently fixes the issue (test server). Cutting a release and announcing it so others can test it (p.s. public XSS issue has a fix now too, just working with security team to solve it and remove the warning when installing the plug-in -- for a subsequent release). Merging.