Dev/bar 120 attempt 2

[mikewallace1979]

This is functionally-equivalent to #867 however the different conninfo strings for WAL streaming are managed before creating the server.

The general idea is that:

1. barman backup and most other barman commands create barman.server.Server objects using the conninfo and streaming_conninfo in the configuration as usual.
2. barman receive-wal and barman cron create barman.server.Server objects using wal_conninfo and wal_streaming_conninfo if they are set but useconninfo and streaming_conninfo otherwise.
3. barman replication-status will use either, depending on the value of its --source option (which defaults to the backup conninfo, to preserve existing behaviour).

This works quite nicely however:

1. We need to be sure this is a safe thing to do. Might barman cron need to use the backup-host conninfo strings for some reason? Are there other barman commands which should have the WAL conninfo?
2. barman check still needs work because it is checking the complete configuration of the Barman server.

Point 2 is addressed by the second commit in this PR where we make barman check get the WAL streaming status and carry out the relevant checks using that.

For point 1 we can do some careful review.

Overall this seems cleaner than #867 and does not require the scattergun changes to barman.server.Server which are present in that PR.

Related: Integration tests.

[mikewallace1979]

This PR definitely looks better than the previous one. I'm posting a few thoughts.

Thanks for reviewing the draft PR @barthisrael - I implemented all of your suggestions so far 😄

There will be a few follow additional commits with unit tests and docs, plus any other changes we determine we need as we continue to think about this patch.

[edb-sonar-app[bot]]

Quality Gate passed

Kudos, no new issues were introduced!

0 New issues
0 Security Hotspots
98.6% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube