⬆️(collaboration) upgrade yhub to 0.9.0 and delete superseded blobs

The S3 persistence plugin records the version id of the object it wrote
and names that version when it deletes it. On a versioned bucket - what
a deployment runs - a delete that names no version deletes nothing: it
writes a delete marker and keeps every version underneath. Each
compaction supersedes the blobs of the one before, so what was kept was
every version of every document ever written, a document someone asked
to erase included, still readable by anyone who can list versions. On
AWS this needs s3:DeleteObjectVersion, which a policy granting
s3:DeleteObject alone does not cover.

Blobs are written to the bucket for every branch of a document.

YHUB_S3_PERSISTENCE now governs only whether new blobs are written
there. The plugin itself is attached whenever the YHUB_S3_* settings
name a bucket, on or off, because reading is the half that must never
be taken away: a row pointing at an object is unreadable without the
plugin that wrote it, and yhub reports such a version as having no
content rather than as an error. Turning the toggle off stops the
writing and leaves the reading alone; it is the settings, not the
toggle, that a deployment whose bucket holds anything must keep. Half a
configuration is a startup error naming what is missing, as before.

The dev stack keeps the toggle off and creates its bucket versioned, so
flipping it on exercises what a deployment runs rather than a simpler
case. Its createbuckets job needed fixing to do so: the folded yaml
block joins its lines with a space, so the trailing backslashes reached
the shell as an escaped space glued to the next word and everything
past the first && silently did nothing - the media bucket never had
versioning enabled either.

Signed-off-by: Kevin Jahns <kevin.jahns@protonmail.com>

env.d/development/yhub

@@ -34,11 +34,15 @@ LEGACY_S3_ACCESS_KEY_ID=impress
 LEGACY_S3_SECRET_ACCESS_KEY=password
 
 # Document storage: where the blobs of a compaction are written. Off, they stay
-# in yhub's postgres, which is what this stack runs. Turning it on stores them
-# in object storage instead — here the same minio, in a bucket of its own that
-# the server creates on startup when it is missing. Read the "Document storage"
-# section of src/yhub-server/README.md first: a document persisted this way
-# cannot be read back with the plugin turned off again.
+# in yhub's postgres, which is what this stack runs. On, they go to object
+# storage instead — here the same minio, in a bucket of its own, created
+# versioned by compose so that flipping this to true exercises what a
+# deployment does rather than a simpler case.
+#
+# The settings below are read whether or not the toggle is on: they are what
+# attaches the S3 plugin, and the plugin is what can read back the objects a
+# previous run wrote. Only the writing follows the toggle. See the "Document
+# storage" section of src/yhub-server/README.md.
 YHUB_S3_PERSISTENCE=false
 YHUB_S3_ENDPOINT_URL=http://minio:9000
 YHUB_S3_ACCESS_KEY_ID=impress