On core performance page, warn about honeypot's disabling of page cache.

This makes sense to me. I'll try it out, and also will need to get it in D8 before adding to D7/D6 versions.

Captcha 8.x-1.0-beta1 shows the following warning message at /admin/config/development/performance
"The CAPTCHA module will disable the caching of pages that contain a CAPTCHA element."

Are there still plans to add the warning message for the Honeypot module on the performance page?
"Page caching may be disabled on any pages where a form is present due to Honeypot module's configuration"

New features should first go into the most current version of this module, then be backported if there is community interest.

I like the idea of putting this warning on the performance page, because that is where people look for performance settings, especially with regards to caching.

The Honeypot configuration pages do have this warning right now, but it would be nice to have it at a higher level.

I looked at what CAPTCHA did (see #4) but I find that intrusive so I would rather go with what @krisahil proposed in #1.

Here's a re-roll of #1 to work in D8/D9 and to apply to the 2.0.x branch.

The code change looks fine. (Honestly the code looked fine 7 years ago too.) It's a very low risk change.

I was just hit with this issue today - we had enabled honeypot on a form in our sitewide footer and lost all our caching. Luckily we do performance monitoring to be able to catch it. Took hours to track it down. If there had been this alert on the performance page, we would have caught it quickly as that was one of the first places we checked.

Honestly the code looked fine 7 years ago too.

To be clear, I've been a co-maintainer of this module for all of 1 month. What I did first is to go through ALL of the issues to triage them and figure out what to do about them. You can see that, for this issue, I first confirmed the issue then moved it to the latest 2.0.x version because that's where it has to be fixed now. I found and evaluated another issue in the queue which touched on the same problem. I made a decision that this issue was both older and better positioned to deal with the problem, so I closed that other one with a comment that linked to this issue. Then I read through the two proposed solutions in this issue, edited the issue summary, then posted my opinion, and then re-rolled the D6/D7 patch to work on D8/D9 in the 2.0.x branch.

Then I waited for community input as to whether this patch addressed the needs of the community.

@Jody Lynn: You're the first community member in 7 years to chime in and say this patch is useful.

I can't speak for anything else having to do with this module prior to the last month, but I don't feel I should have to take the blame for long-delayed issues just because I stepped up to help. The Drupal community has seriously disengaged from the issue queues since D7, but without community input we can't move forward. Relying on volunteer maintainers to do all the work and answer all the questions and fix all the bugs by themselves is just not a sustainable model for open source. The people who make money using this module (not me, BTW) are the ones that need to be giving back to the community, in the form of patches and reviews and and answering support questions in the issue queue, but I just don't see any of that happening anymore for most of contrib.

Committed #8 with coding standards fixed.