Plumbing for a downstairs to track if it has been active.

[leftwo]

This does the downstairs side plumbing (getting ready to receive new messages) in
support of the been active state that will help us with the 2/3 activation work coming
behind it.

Add an active.json file next to region.json that records whether an upstairs has ever
told this downstairs it was active. The format is a version-tagged JSON object:
{"version": "v1", "been_active": false}.

A new region starts with been_active false.
Region creation fails if active.json already exists, just as it does for region.json.
A read-write open of a region without the file creates the file with false.
Read-only regions always report true and never touch the file.

set_been_active() moves the flag from false to true and persists it. It is a no-op if
the flag is already set or the region is read-only.

The file is local to each downstairs. Repair only serves extent files and clone
creates the region locally, so it is never copied.

Added tests to verify the behavior, and threw in a test to make sure neither
region.json nor active.json show up in the list of files for repair.

A question in the comments: What should we do if we can't read the active.json file?
It's not really fatal to the overall downstairs, we can fall back to false and no
harm done (but no 2/3 activation). However, an error reading the file means
something is wrong.. so.. ??

[jmpesp]

Read-only regions always report true and never touch the file.

set_been_active() moves the flag from false to true and persists it. It is a no-op if
the flag is already set or the region is read-only.

I get why it should be a no-op to set the flag for a read-only region, but am curious why we should always return true for read-only regions? I would imagine the Upstairs shouldn't be asking about been_active for read-only activations, maybe we should count that as an error instead?

[leftwo]

Read-only regions always report true and never touch the file.
set_been_active() moves the flag from false to true and persists it. It is a no-op if
the flag is already set or the region is read-only.

I get why it should be a no-op to set the flag for a read-only region, but am curious why we should always return true for read-only regions? I would imagine the Upstairs shouldn't be asking about been_active for read-only activations, maybe we should count that as an error instead?

Yeah, I could see that viewpoint too.
Move the "ignore this if read-only" up into the upstairs, and then have a downstairs that is read only return an error if someone asks it for "been active" status? It probably makes better sense to do it that way instead of having the upstairs send messages that both the upstairs and the downstairs know is going to be ignored. It means a slightly different negotiation path for read only clients maybe? That was the piece I was thinking we would get to avoid by sending then ignoring from the upstairs, all clients have the same negotiation steps, but some are not used in the RO path.

The RO path is a bit bolted on, and I say this reflecting on my own work here. We could probably structure things a bit different overall.

Hmm. I convinced myself you were right, and then talked myself back to being unsure. Let me go look at what it would take to make the upstairs not send the request. Maybe it will be okay, as I will already need to special case V13 downstairs to not send "been active", so perhaps the check is `"if (version < v14 || read_only), don't send been_active"

I have typed a bunch of words and I have not gotten any closer to an answer.

[leftwo]

I've done the refactor to make read-only refuse to answer if it has been active.