Clean up network setting docs

[DaveCTurner]

• Add types for all params
• Remove mention of JDKs before 11
• Clarify some wording

Co-authored-by: Stef Nestor [email protected]

[elasticsearchmachine]

Pinging @elastic/es-docs (Team:Docs)

[elasticsearchmachine]

Pinging @elastic/es-distributed (Team:Distributed)

[lockewritesdocs]

Left some suggested changes based on the setting type and the default values.

[lockewritesdocs]

Suggested change

	Configures whether detailed errors may be returned in HTTP responses. Defaults
	to `true`, which means that HTTP requests which include
	<<common-options-error-options,`?error_trace` URI parameter>> will return a
	detailed error message including a stack trace if they encounter an exception.
	Configures whether detailed errors are returned in HTTP responses. Defaults
	to `true`, which means that HTTP requests that include the
	<<common-options-error-options,`?error_trace`>> parameter will return a
	detailed error message including a stack trace if they encounter an exception.

[DaveCTurner]

I think may be is correct here. By default we don't return detailed errors even if http.detailed_errors.enabled: true - this setting just permits the use of the ?error_trace parameter.

[DaveCTurner]

See 72be4ee for an alternative.

[lockewritesdocs]

Suggested change

	it sends TCP keepalive probes. Defaults to `network.tcp.keep_alive`.
	it sends TCP keepalive probes. Defaults to `true`.

[lockewritesdocs]

This is a boolean setting, which I believe defaults to true.

[DaveCTurner]

Thanks @lockewritesdocs. The transport.* and http.* settings largely fall back to the network.* ones so the changes you've suggested are not quite accurate. For instance if you set network.tcp.keep_count: 5 then transport.tcp.keep_count defaults to 5, not to -1. That's why we say that they default to the fallback setting in each case.

[lockewritesdocs]

Thanks for the explanation @DaveCTurner. I resolved the comments relating to suggested changes on those settings. Merge away 🦖

[elasticsearchmachine]

💔 Backport failed

Status	Branch	Result
❌	8.3	Commit could not be cherrypicked due to conflicts
✅	8.4

You can use sqren/backport to manually backport by running backport --upstream elastic/elasticsearch --pr 88929

[lockewritesdocs]

@DaveCTurner, it looks like the 8.3 backport failed.

[DaveCTurner]

Thanks, yes, I did a custom bespoke artisanal backport to 8.3 in a42fc90.

[lockewritesdocs]

Thanks, yes, I did a custom bespoke artisanal backport to 8.3 in a42fc90.

I'm assuming that you physically lifted the changes into the 8.3 branch, and then used a vintage bellows to propagate them through the code base.