The streaming replication built into PostgreSQL would work fine for your use case, assuming that you are OK with having only one primary supporting writes and any slaves being read only as it currently (9.0-9.4) only supports a single master. This will put minimal load on your primary server and in most cases will get you what you need. An excellent benefit of using the built in streaming replication in PostgreSQL 9.4 or newer for WAN replication is that with Replication Slots the master will keep track of when the slave gets disconnected or falls behind and will retain WAL logs as necessary. It puts minimal load on the master as the WAL logs are written regardless and adding additional details to them are cheap. Slony and Bucardo use triggers which put transactional load on the master, and aren't really feasible over a distant WAN.
A common configuration is to have master-slave replication set up via streaming replication and using pgpool-II to load balance. pgpool-II can be configured to send all the writes to the master and distribute selects to both. However, this will not get you all the desired HA you want because pgpool-II does not have any logic to promote the slave to become the new master if the master goes down. It is very easy to promote a slave to be a master (you simply create a file that triggers auto-promote, then reconfigure pgpool or do a DNS switch to point the application there) but to have failover completely automated is much more complicated and pgpool-II will not get you there.
The built in streaming replication can only replicate your entire PostgreSQL cluster, so if you need finer grain control over what to replicate (for example only a particular database of the cluster) you will need to look to one of the other tools, such as Slony.
I would also recommend you take a look at the BDR Project from 2ndQuadrant. The docs are located at
http://bdr-project.org/docs/stable/index.html. Like Bucardo it provides master-master replication capabilities with conflict resolution which may allow you to avoid having logic differentiating write transactions and directing them to a particular PostgreSQL Cluster, and will avoid you having to have logic to promote slaves in the case of failure of the master. Unlike Bucardo it uses streaming replication rather than triggers so load on the master is minimal. The primary components of the BDR project are being incorporated into core PostgreSQL and will very likely be part of the standard streaming replication in PostgreSQL 9.5 and above.
