ReadWrite: add an alternative FinalizeReadOnly+Close flow

[MichaelMure]

The goal being to be able to keep reading blocks and the index after safely finalizing the file on disk. Typically for indexing purpose.

More tests are likely required, but PR for early feedback.

fix #375

[willscott]

this looks fine to me in terms of structure.

A test would probably not hurt to make sure we don't break the functionality in the future

[willscott]

should we finalize in this case?

[MichaelMure]

hmm maybe? TBH, if I had to write that code from zero I would just panic(), as that's a clear developer problem.
Up to you, I can add it.

[rvagg]

If we make this also finalise then we could eventually deprecate Finalize() so that Close() is always what you call at the end of use of a readwrite, you just have the option of also making it readonly before you do that. So I think my vote would be to add a finalisation phase in here if it's not already done, then we could update docs to make it clear you can do either.

[MichaelMure]

This is a bit odd to me. When working on a file, there is two outcomes: Finalize() and Discard(). Here you want, in the odd case that the caller didn't choose one, arbitrary choose Finalize()?

With the current PR, you get three clear paths:

• Discard()
• Finalize()
• FinalizeReadOnly() + Close()

If Close() also finalize, we get:

• Discard()
• Finalize()
• Close()
• FinalizeReadOnly() + Close()

I get that you might want this (although the current PR version look more obvious to me):

• Discard()
• Close()
• FinalizeReadOnly() + Close()

In that case, I'd suggest to go there in one go, and skip the confusing in-between.

[MichaelMure]

I added a test. It should be good to go, depending on what you want with #376 (comment).