Docs: Update "Choosing parameters" to align with RFC 9106

[ftes]

The "Choosing parameters" guide references "the Argon2 draft guidelines" and walks users through a time-first tuning process:

Decide how much time each call should take.
The Argon2 draft guidelines recommend 500 milliseconds (0.5 seconds).

RFC 9106 (2021)¹ inverts this: maximize memory first, then set iterations.

If a uniformly safe option that is not tailored to your application or hardware is acceptable, select Argon2id with t=1 iteration, p=4 lanes, m=2 GiB [...]. This is the FIRST RECOMMENDED option.
If much less memory is available, a uniformly safe option is Argon2id with t=3 iterations, p=4 lanes, m=64 MiB [...]. This is the SECOND RECOMMENDED option.

Current defaults vs. recommendations

Source	t_cost	m_cost (memory)	parallelism
argon2_elixir	3	16 (64 MiB)	4
RFC 9106 first	1	21 (2 GiB)	4
RFC 9106 second	3	16 (64 MiB)	4

The current defaults match the RFC's second, memory-constrained recommendation. They also exceed the OWASP minimum recommendations². For reference, Python's argon2-cffi³ also defaults to the RFC 9106 low-memory profile (since v21.2.0) but explicitly documents both profiles and exposes them as RFC_9106_HIGH_MEMORY / RFC_9106_LOW_MEMORY.

Suggested changes

1. Update docs to reference RFC 9106 instead of "the Argon2 draft guidelines" and recommend a memory-first tuning approach. Also mention first and second recommendation in the docs.

2. Note the Out of Memory risk for high m_cost values: each concurrent hash allocates memory in native C space with no built-in concurrency limit.

3. Optionally expose RFC 9106 profiles (like argon2-cffi does) so users can easily opt into the high-memory configuration.

References

Footnotes

1. RFC 9106 §4 ↩

2. OWASP minimum recommendations ↩

3. argon2-cffi parameters ↩

[ftes]

I'd be happy to create a PR! But since I'm not in expert in this field, I wanted to discuss this in an issue first.