Make iterator_proxy_value a forward_iterator (#4371)

[captaincrutches]

See #4371 for all the details - but long story short, there seems to be no reason not to expose iterator_proxy_value as a forward_iterator instead of just an input_iterator. This allows more use cases when items() is fed into C++20 std::views.

If there is a reason not to do so, please let me know - but the iterator_category on this type currently seems to long predate the more recent change to fix it for C++20 ranges initially. As well, the actual json iterator which the proxy wraps is also a forward iterator, so this keeps them on par with each other in terms of capabilities.

Another option is to remove this iterator_category typedef entirely, and let iterator_traits deduce it - since the type otherwise satisfies ForwardIterator, it should (and does, in my motivating case) do the right thing. But since the other required typedefs are here, might as well keep it but change it IMO.

I'm not sure what, if any, tests can/should be updated/added in this case - I'm open to suggestions, though it seems like all the relevant static_asserts and such should still apply.

---

Pull request checklist

Read the Contribution Guidelines for detailed information.

• Changes are described in the pull request, or an existing issue is referenced. (iteration_proxy has limited usefulness in C++20 range views #4371)
• The test suite compiles and runs without error.
• Code coverage is 100%. Test cases can be added by editing the test suite.
• The source code is amalgamated; that is, after making changes to the sources in the include/nlohmann directory, run make amalgamate to create the single-header files single_include/nlohmann/json.hpp and single_include/nlohmann/json_fwd.hpp. The whole process is described here.

Note on amalgamation: I did run make amalgamate, and that touched a bunch of lines unrelated to my change. The actual change I've made is to iterator_proxy.hpp, and hopefully hiding whitespace in the diff will narrow that down. If you'd rather I revert the other amalgamate changes to keep this diff confined to the 2 (well, 4, including generated code) lines I changed, I'm more than happy to do so - but I figured I'd err on the side of caution w.r.t. any checks that run in CI.

[captaincrutches]

Ahh - I see from the build logs that these jobs use astyle 3.1; when I ran make amalgamate, I installed astyle 3.4.

Re-running with the matching version of astyle produces much saner results :) Though it still does remove a bunch of blank lines in the single-include headers.

[github-actions]

🔴 Amalgamation check failed! 🔴

The source code has not been amalgamated. @captaincrutches
Please read and follow the Contribution Guidelines.

[coveralls]

coverage: 100.0%. remained the same
when pulling 104cdd8 on captaincrutches:cc-iterator
into 8c391e0 on nlohmann:develop.

[captaincrutches]

Okay, I reset the single-include files entirely and tried again, and now we've got a diff that actually looks correct. Sorry for the noise! I'm happy to rebase and clean up these extra bad commits if that would be preferable.

[captaincrutches]

Clang-tidy failures look unrelated to my change - looks like #4311 already exists trying to fix them.

I'm not sure what to make of the xcode 12.4 build - seems like something stalled out and hit a timeout, but I can't tell what... the rest of the build looks like it was going fine up until it stopped in its tracks.

[nlohmann]

I'll check the Clang-Tidy warnings.

[captaincrutches]

Updated now that CI is fixed, to pick up those changes. Also squashed down all the amalgamate weirdness from before.

[gregmarr]

LGTM

[nlohmann]

Looks good to me.

[coveralls]

coverage: 100.0%. remained the same
when pulling 44f7c9a on captaincrutches:cc-iterator
into 1825117 on nlohmann:develop.

[captaincrutches]

Clang-tidy failure looks like a readability-container-contains in unit-readme.cpp, which may indeed have been introduced by this change if making this a forward iterator causes the json type to more closely model Container and therefore AssociativeContainer.

Looks like there's already a case of this warning that's suppressed by the recent CI-fixing change, I assume because contains is only in C++20 for std containers that have it.

On the other hand, this one looks like it's operating on a json object, which does have contains, and the line being pointed to is many years old, so maybe updating it to use contains is the right thing to do.

I'll defer to you guys here, since it seems a bit of a hot topic: should I fix the warning, or suppress it for now?

[nlohmann]

Please add a NOLINT comment.

[nlohmann]

FYI: The same issue occurred on the CI of #4036, so it was not introduced by this PR. I have no idea what changed since merging #4489. Nonetheless, if you suppress the line, we have a green CI and can merge this.

[nlohmann]

Thanks a lot!