Add std::unordered_set support and a helper BuildList to dedup list build handlers

[ViniciusCestarii]

Add std::unordered_set support and a helper BuildList to dedup list build handlers that is being used for map, set and vector.

While looking bitcoin/bitcoin#29409, found a TODO noting that libmultiprocess lacked std::unordered_set support, requiring downstream that PR to implement the build/read functions locally.

I believe there could be more dedup adding a ReadList too. I could do that as a follow-up if desirable

[DrahtBot]

The following sections might be updated with supplementary metadata relevant to reviewers and maintainers.

Reviews

See the guideline for information on the review process.

Type	Reviewers
ACK	ryanofsky

If your review is incorrectly listed, please copy-paste <!--meta-tag:bot-skip--> into the comment that the bot should ignore.

Conflicts

Reviewers, this pull request conflicts with the following ones:

• #288 (Create support branch for CI scripts, documentation, and examples by ryanofsky)
• #276 (build: prepare for subtree split by Sjors)

If you consider this pull request important, please also help to review the conflicting pull requests. Ideally, start with the one that should be merged first.

[ryanofsky]

Code review ACK 00c9a8e. This is a well-implemented change that simplifies bitcoin/bitcoin#29409, and could help other places, since unordered_sets are used for various things in bitcoin core, and it makes sense to allow them to be easily passed over capnproto interfaces.

I believe there could be more dedup adding a ReadList too. I could do that as a follow-up if desirable

Yes this would be a nice followup, especially since type-set.h and type-unordered-set.h files are almost exact duplicates of each other and other read functions are very similar. Might be possible to write a generic ReadList that works for all containers by taking an init(size) callback and an emplace(args...) callback.

[ViniciusCestarii]

The new optional_int field on master uses a proper camelCase capnp name (optionalInt) with $Proxy.name mapping to a snake_case C++ member, which reads cleaner than the older lowercase style (setint, vbool). Should I follow that pattern here and rename unorderedsetint to an unorderedSetInt capnp field with a snake_case C++ member?

No need to touch the existing setint/vbool fields here. I believe that cleanup could be a separate PR.

[ryanofsky]

Should I follow that pattern here and rename unorderedsetint to an unorderedSetInt capnp field with a snake_case C++ member?

Anything seems fine to me, would choose whatever seems cleanest to you. Feel free to include a commit renaming existing fields in this PR too if you'd like

[ViniciusCestarii]

Forced-push 9de4b88 rebasing and fixing conflict with master and added the commit 9de4b88 "test: use camelCase + $Proxy.name for FooStruct fields"

[ryanofsky]

Code review ACK 9de4b88. Only changes since last review were renaming and adding commit user better field names in the test.

[ryanofsky]

In commit "test: use camelCase + $Proxy.name for FooStruct fields" (9de4b88)

Not important but vector_bool would seem more consistent with other field names

[ViniciusCestarii]

I agree. If in the future I touch these code lines again I will apply this suggestion. Thanks for the feedback!