stack 2.23.0

Stack 2.23.0

Features

• Renaming a group keeps its PostgreSQL and S3 data: the next stack up of
  the repository that contributed it moves the data to the new name, renaming
  the group's database and role, explicit databases' roles, and its S3
  stores with their policies. Other services start empty under the new name
  and keep the old data, which stack up reports.
• stack serve [directory] serves a plain folder's files as a static site,
  without a stack.yaml and without writing anything into the folder. It
  answers at <name>.test, a group of its own named after the folder
  (lowercased, anything else becoming a hyphen) unless --name says
  otherwise, lasts as stack up does until stack down, and takes
  --always, --open and --json. It refuses a folder holding a
  stack.yaml, the home folder, the filesystem root and a folder another
  account owns, and a served folder never shares its group with a repository.
• The daemon API: a link request's folder serves dir that way, and the
  repository views in status and the down reply carry folder: true for
  one.
• stack prune also deletes the logs nothing writes any more: those of
  sites and services that are gone or no longer served. They are listed with
  the unused versions and go with the same confirmation; the daemon API lists
  them under logs in /v1/installs and takes log_names in /v1/prune.
• Site reports name the S3 service a gateway or published bucket site
  answers for (service) and the repository declaring it (dir).
• Following a log through the daemon API takes lines=<count> (up to
  100000) or lines=all, so a client can show more than the last 200 lines;
  without it the stream starts as before.

Fixes

• Moving or deleting a registered repository no longer breaks stack up, the
  shims or the reports: each skips it with a warning, stack status lists it
  as missing, and stack up in its new directory takes the registration over
  (keeping --always) when it is the group's only vanished one. stack prune
  still waits until it is served again or unlinked.
• A configuration edit, preview included, that gives a group with an S3
  service a site named s3 is refused as serving refuses it, instead of
  being written and then failing at stack up.
• A program started without the shell's PATH, such as Stack Desktop opened
  from Finder, could not find the installed stack: stack doctor reported
  the ports service as unknown, and stack setup took the paths meant for a
  development build. The CLI now also looks where install.sh, install.ps1
  and Homebrew put it, never at its own executable.

Compatibility

stack.yaml and stack.local.yaml are unchanged. The daemon API only gains
fields: folder on link requests, repository views and the down reply,
lines on /v1/logs/stream, logs in /v1/installs, log_names with
logs_removed and logs_bytes in /v1/prune, service on site views and
missing on repository views.
After going back to an older daemon, a served folder stays listed as a
repository whose stack.yaml is missing; stack unlink forgets it.