Incorrect `republishToDlq` property default value in documentation

[ViliusS]

Describe the issue
Documentation about republishToDlq property says that the default ir false but it is actually true. I tried to come up with PR for this but it looks like .adoc has already correct value (true) so I have no idea how documentation website still generates false.

Also, some time ago the default value changed to true but property description was never changed, so it is unclear if By default... in a text actually means true or false.

Screenshots

[ViliusS]

@olegz description is still a little incorrect after latest PR. The part about frameMaxHeadroom property was additional explaining part of the stack trace sentence. It gives additional information how to expand headers if stack trace doesn't fit into DLQ message if republishToDlq is true. In this latest PR it now becomes disconnected from context. It is now difficult to understand why this property is referred to.

[olegz]

@ViliusS Thank you for pointing this out. How is this cbc5855

[ViliusS]

@olegz sorry, I still think it is confusing and little bit incorrect. Specifically, what "by default" in this case means, does it mean by default in RabbitMQ broker, or by default setting of this property? If the latter, it is incorrect as default is now true. My suggestion would be to loose first sentence and change wording like this:

If a dead-letter queue (DLQ) is configured the binder republishes failed messages to the dead-letter queue.
When this property is set to `true` (the default), the binder will add additional headers to the failed message, 
including the exception message and stack trace from the cause of the final failure. Also see xref:rabbit/rabbit_overview/rabbitmq-consumer-properties.adoc#spring-cloud-stream-rabbit-frame-max-headroom[frameMaxHeadroom property] for the information about truncated stack traces.
When `false`, messages will be routed to the DLQ in its original form without extra headers.

[ViliusS]

Additional finding. The same page above says, that republishToDlq enables delivery to DLQ:

I don't remember how this option works exactly, when I tested it during creation of this issue, but it looks like in some places documentation implies, that in order for DLQ publishing to work one needs republishToDlq set to true. But in other places it says that this parameter is only related to how messages are puiblished to DLQ, not if they are published.

I guess there were some changes in code and documentation through time, but not all places were updated. More deep investigation is probably needed what is really true.