chore(electric): Flip the default value of DATABASE_REQUIRE_SSL to true

[alco]

This is a better default for any environment other than, perhaps, dev.

Until now, connecting to a Postgres that was configured to only accept SSL connection would result in a cryptic invalid_authorization_specification error (FWIW the same error may be logged when Postgres is configured to only accept unencrypted connection, but this is a rare edge case). That was the case with Crunchy Bridge and AWS RDS.

With this new default, more hosted databases should be supported out of the box. One prominent exception is Fly Postgres (at least prior to its takeover by Supabase): since Fly machine all connect to the same encrypted private network, there is no benefit of an additional encryption for database connections on top of that. For cases like this, we need to print a friendly error message instructing the developer to set DATABASE_REQUIRE_SSL=false in their Electric configuration. This will be addressed in #762.

Note that Electric also needs to be able to verify the database host's authenticity to prevent man-in-the-middle attacks. I've filed VAX-1446 to address this at a later time.

Also, the added burden of setting DATABASE_REQUIRE_SSL=false in dev is not lost on me. I'm implementing support for .env files in #770. That will remove some configuration-related woes in dev.

[magnetised]

I'm sure you've thought about this but isn't there an "optimistic" version of this setting that will try ssl then fallback if it doesn't work? wouldn't that work everywhere? in this pr you refuse use of the sslmode param but isn't sslmode=prefer exactly the behaviour we want? i.e. the client sends an SSLRequest message and the server responds with either S or N

[alco]

@magnetised This PR bundles a couple of independent changes:

• enforcement of SSL connections by default. What you're saying about sslmode=prefer can be achieved by setting DATABASE_REQUIRE_SSL=false. But I don't think it should be the default for production deployments. So far we've roughly followed the "secure by default" approach with AUTH_MODE being set to secure by default.

  Of course, it can be argued, that a database is probably always hidden from the Internet in a private network in production deployments, but I'm not sure that's valid anymore. Hosted PGs like Supabase and Crunchy Bridge make it easy to connect to them over the public Internet.

• rejection of DATABASE_URL if it has the sslmode query param. This is because we don't intend to support all of the sslmode values that psql supports. I remember originally asking for this option to be supported but I've reversed my position on this topic after doing some research into the use of SSL with Postgres and how the pg_hba.conf file can be used to restrict incoming connections based on host and encryption rules.

[magnetised]

@alco thanks for the clarification.

[alco]

FYI I had to implement SSL support in the proxy because it wouldn't be able to establish an upstream connection when the database was configured to require SSL. I'm baffled at the fact that we haven't noticed this until now.