Improve documentation around WAL streaming/archiving

[mikewallace1979]

We are still recommending setting up WAL archiving as well as WAL streaming but we don't explain why someone would (or wouldn't) want to do that (see https://docs.pgbarman.org/release/2.19/images/barman-architecture-scenario2b.png but also check the rest of the docs). The short answer here is that streaming replication wasn't so reliable before the implementation of replication slots in PostgreSQL so a fallback method was necessary - when replication slots were introduced in PG 9.4, streaming became much more reliable and so fallback WAL archiving is no longer so important. That said, the trade-offs involved in running both may still be favourable with more recent versions of PostgreSQL, e.g. if network bandwidth is not a concern and the impact of streaming replication failing is high then having WAL archiving running as a fallback may be worth it, so that WALs are still shipped in the event of a failed password rotation for example). These are quite deployment/requirement specific so I think it's best for the documentation to just be clear about what is required and what might be helpful.

Related, we don't make it clear that backup_method = postgres cannot work over SSH (vs "not required"), specifically:

This setup, in Barman's terminology, is known as streaming-only setup, as it does not require any SSH connection for backup and archiving operations. This is particularly suitable and extremely practical for Docker environments.

This can lead to confusion for anyone hoping to run pg_basebackup over SSH since such an operation is not possible at all - the reason being that pg_basebackup can use SSL encryption through its PostgreSQL connection so there is generally no need to run it over SSH and pipe the result back.

Finally, one fairly simple omission here (find/replace for the string):

This more robust implementation is depicted in figure .