Automated Drupal 10 compatibility fixes

I have reviewed and checked this automated patch this works for drupal 9.5 and drupal 10.0. and 10.0.1
Screenshots of the compatibility on 9.5 and the functionality on 10 have been attached for reference:

During the Drupal 10 Readiness Initiative meeting, it was discussed whether or not to mark bot issues "RTBC" when humans have successfully tested them and the decision was "yes". So, moving this from to "RTBC" based on the successful testing above. If the maintainer prefers to move this back to "Active" or "Needs review", please just add a note explaining this preference so new contributors leave the issue alone.

@ QED42 employees: Your contributions are perceived as gaming the credit system. This contribution is one of them.

What was done here is perceived as of no value. It is an automated fix, unfortunately it doesn't follow the normal workflow as with human provided patches. The status is Needs review (NR), you should not assign it to yourself to post a review. Your review is redundant. The bot is already telling you these things. There is no need for uploading pictures for things already evident.
Only when that wouldn't be the case, reviews would be helpful.

Would have been nice for the automated fixes to have the same workflow as human provided patches. That would allow to get the attention of a maintainer by setting RTBC. As these issues are addressed at maintainers they should pay attention and commit provided patches when agreeing with their implementation. In order to continue to receive fixes it can't be set to RTBC.

See https://www.drupal.org/docs/develop/issues/issue-procedures-and-etiquett..., in particular no 1 and 10 of things no to do.

Accept automated patches until this issue is closed
If this issue is left open (status of Active, Needs review or Needs work) and the "ProjectUpdateBotD10" tag is left on this issue, new patches will be posted periodically if new deprecation fixes are needed.

As the Drupal Rector project improves and is able to fix more deprecated API uses, the patches posted here will cover more of the deprecated API uses in the module.

Automated fixes are not perfect and error free. Feel free to disagree on the provided solution explaining why you disagree. Possibly provide an alternative. As this patch only adds support for D10 the only helpful review would be when the claim to be D10 compatible was proven false.

Set back to NR as there was no proper review done!

Hey @mmjvb,
My(or our) intention was not to game the credit system.

* Regarding marking automated issue RTBC
* After the first global contribution porting event confusion was raised regarding should automated patch issues be tested or not and if they are tested should they be moved to RTBC or not, After the discussion, it was concluded that unless the maintainer specifically specifies for keeping the issue active we should mark the issue RTBC after verification.

* Regarding assignment of needs review issue
* From this post-https://www.drupal.org/docs/develop/issues/issue-procedures-and-etiquett... " Assign yourself to an issue unless you intend to work on it in a fairly short timeframe. State clearly in the comment where you assign yourself what you intend to do, and when a progress report can be expected. Assigning yourself to issues block others from working on them, so you need to be very careful when doing this."
* From this we understand that if a person is going to work on an issue in a short amount of time then it makes sense for them to assign issues to themselves but it nowhere states that only needs work status-related issues need to be assigned.

* Regarding uploading of screenshots in the issue
* We have discussed in our team while working on reviewing any issue to add proper screenshots which indicate that module functionality is working correctly. The aim is to help easily in understanding the reviewer actually reviewed the patch correctly and is not trying to game the credit system.

As my answer is also a copy you may find things not applying directly to this issue. Consider them still relevant.

- RTBC
Poor decision. Sounds like failure to understand the proces of automated fixes. The whole idea is to make it as easy as possible for maintainer to accept/refuse the patches. Your contributions do the opposite. You are taking away the option the maintainer chose for, being to continue to receive fixes of the bot. He now needs to do something for it. The default way the process works is now disturbed.

Filed https://www.drupal.org/project/infrastructure/issues/3309815 as I agree the proces needs to be improved. Requested it to be conform traditional manual patch flow, unfortunately rejected. The rules are very hard to follow when they are unnecessarily complex.

Doubt very much maintainers want feedback on automated fixes stating RTBC. Especially, the bad ones, where functionality is not properly checked as requested by the bot !
The essentials of the patch #3 are completely missed:
- - The scope creep of removing support is missed
- - There is no mention of running the tests locally as requested by the bot. No deprecations found in the code of the module, but its test code is refactored.
Most reviews lack proper description of scenario's tested, their result and assessment of that result.
In this case consider adding the page about a block showing the cookie as proper confirmation the module works. At least that part, not enough to RTBC !

- Issue assignment
Placing a review is not considered work in this context. Work is perceived as changing the provided patch, for whatever reason. Normally, assignment and setting to Needs work stating what is going to be done would be the action to take for a developer. Only when there is a minor change there is no need for assignment. It is considered unlikely someone else will do the same. When it is, there is not a lot of time wasted. Assignment just informs others there is something coming, a request to hold on and postpone activity. Obviously, reviews/comments are still welcome, despite being possibly missed by developer.

So, you shouldn't assign when placing a review. No need for assignment when starting an issue fork either. Considered prerequisite knowledge of patchers.

- Screen shots
Most of the screen shots are redundant. They confirm claims of the bot, there is no need for. Only when contradicting the bot, they are helpful. Please don't make the mistakes your colleagues made when the bot already informs you the patch doesn't make it compatible.
The bot will adjust core_version_requirement to include ^10 when it considers it compatible. Making it compatible is not a requirement for this issue. This issue is about repairing deprecated code, not requiring to be complete. Determining it is D10 compatible is just a bonus.
In addition stop introducing scope creep by adding reports of drupal-check. Very annoying to include the screen show where it is much more helpful to include the transcript of the terminal session. At least then we see what was done. Feel free to create an issue when you fell what is reported needs to be resolved. Only point out D10 compatibility issues here. Check the queue for already reported issues. Just reporting the output is not considered helpful. Relate that information to something helpful for the maintainer, otherwise don't waste their time even reporting it.

As there are no changes other than core_version_requirement there is no need to confirm the bot by the screen output of upgrade_status. The functionality of block_cookie should be tested, not the testing tools themselves.

Hey @mmjvb,
Thank you for your feedback. I'll keep in mind all the points you mentioned next time.

Issue resolved in V2.0.2