Use Erlang 26 features

[janl]

This issue is an experiment nicked from the Elixir project. Whenever a new Erlang version comes out, they go through the release notes and note any new features or issues that might affect Elixir. We should do the same for CouchDB.

Since we support older versions of Erlang, we usually can’t start adopting new features when they come out (unless we version-guard them, in cases where it is warranted, like opting into a substantial speedup on newer versions), but at least we have a check-list for things to adopt when the new Erlang version some day becomes our oldest-supported version.

Here’s a start from the Erlang 26 RC1 release notes and more detailed Readme:

• Time Warp Mode, possible incompatibility.
• JIT improvements: measure how much they impact CouchDB vs. Erlang 25.
  • TODO: determine a useful measurement
• Maps:
  • Are there places where we can benefit from map comprehensions?
  • Do we rely on map key sort order anywhere?
• Misc ERTS, Stdlib, Kernel, Compiler:
  • “Improved the selective receive optimization, which can now be enabled for references returned from other functions” how can one opt into this and does this help us? — Found this PR implementation, but not a lot smarter after reading it :) — this (earlier?) PR also mentions receive optimisations.
  • “It is no longer necessary to enable a feature in the runtime system in order to load modules that are using it. It is sufficient to enable the feature in the compiler when compiling it.”
    • Are we doing any of that and can we stop it now?

[nickva]

Great idea, @janl.

A good page to keep an eye on is upcoming_incompatibilities

For clouseau (search) which implements its own dist protocol there are some things to fix up:

• DFLAG_V4_NC
• New link protocol is mandatory

A tricky one may be that term_to_binary is changing:

• erlang:term_to_binary/1,2 and erlang:term_to_iovec/1,2 will now encode atoms as UTF8 by default. We use term_to_binary for on-disk storage. I think we can try toggling {minor_version, 2} in more places to ensure we use a forward compatible format. As far back as R16 can already read that format. A potential pitfall here is a case where in the compactor we may not necessarily re-encode all doc bodies or other bits when we copy. That means we could potentially carry forward future-incompatible compression format, or term_to_binary ({minor_version, 0} ?) or such without noticing or compaction having a way to upgrade it.
• erlang:term_to_binary/1,2 has a new deterministic option since OTP 24. can be used to ensure that within the same major release of Erlang/OTP, the same encoded representation is returned for the same term. There is still no guarantee that the encoded representation remains the same between major releases of Erlang/OTP. wonder if there is any need or use for that.