Handle connection string for unix sockets correctly

[samu698]

When using connection strings with unix sockets the path should be interpreted as the path to the directory that contains the unix socket rather than the path to socket itself as per spec here:
https://www.postgresql.org/docs/current/libpq-connect.html#LIBPQ-CONNECT-HOST

Name of host to connect to. If a host name looks like an absolute path name, it specifies Unix-domain communication rather than TCP/IP communication; the value is the name of the directory in which the socket file is stored.

The port also can be specified in the URI parameters, as per spec:
https://www.postgresql.org/docs/current/libpq-connect.html#LIBPQ-CONNECT-PORT

Port number to connect to at the server host, or socket file name extension for Unix-domain connections.

The name of the socket is based on the configured port in PostgreSQL this PR also handles this case by generating the socket file name based on the specified port.
https://www.postgresql.org/docs/current/runtime-config-connection.html#GUC-UNIX-SOCKET-DIRECTORIES

In addition to the socket file itself, which is named .s.PGSQL.nnnn where nnnn is the server's port number

This change would be breaking for current users that rely on current behavior, I can fix this by supporting both possibilities, but this would add complexity and support an out of spec behavior.

Fixes: #297

[straight-shoota]

I suppose it shouldn't be too hard to keep a fall back for the old behaviour to avoid breaking?
We probably don't need to cover every possible use case.
It should be sufficient to rewrite the host if it is a pathname including /.s.PGSQL., we replace it with its parent path (the part before the match) and set @port accordingly. That should probably cover any relevant use case. I doubt anyone would be using a socket name that doen't match the naming scheme.

[samu698]

Ok that is a simple enough solution for backwards compatibility, I will implement it soon

[samu698]

Thanks for the review and the helpful suggestions.

I added the check for backwards compatibility by removing the socket name suffix if it is found. I decided against adding a test for it because I think it should be considered just a fix and deprecated behavior (if you prefer otherwise I can add it).

I changed the check for detecting when to use a unix socket to this:

if Path.new(@conninfo.host).absolute?

So that the check also work on windows when a drive letter is found, matching the libpq docs

On Windows, paths starting with drive letters are also recognized.

On windows the SOCKET_SEARCH paths do nothing as they are based on unix, to fix this we could detect the OS and search different paths, but I'm not sure what paths to put there.

[will]

Thanks! I just updated the CI to run with newer versions of crystal and the current set of supported Postgres versions. Could you rebase on that, and then also add a line to the changelog for this?

[samu698]

Ok great! I'll add a line to the changelog.

I don't understand what should I do, to which branch should I rebase?

[will]

There is just one new commit on master c50de77 that I put there an hour or so ago.

There is a button I can push here on this PR that can do it, I'll push it now but just know there'll be a commit on your branch you didn't do. That can sometimes cause annoying git problems if the other person isn't aware it happened.

[will]

Thanks!

[samu698]

There is just one new commit on master c50de77 that I put there an hour or so ago.

There is a button I can push here on this PR that can do it, I'll push it now but just know there'll be a commit on your branch you didn't do. That can sometimes cause annoying git problems if the other person isn't aware it happened.

Ah ok no problem, I didn't notice your new commit