eliminate internal tracking of EOF

[rnewson]

Overview

Manually tracking is error-prone. e.g, file:write might return ok but not have written all bytes due to buffering. couch_file advances the eof anyway, so the results of subsequent writes before a datasync will return the wrong position. calling file:position/2 is very cheap, so just do that when we're writing.

Testing recommendations

Covered by eunit tests.

Related Issues or Pull Requests

N/A

Checklist

• This is my own work, I did not use AI, LLM's or similar technology
• Code is written and works correctly
• Changes are covered by tests
• Any new configurable parameters are documented in rel/overlay/etc/default.ini
• Documentation changes were made in the src/docs folder
• Documentation changes were backported (separated PR) to affected branches

[rnewson]

noting this might make the read_beyond_eof handling code unreachable (iirc we added that when we speculated sources of eof tracking being wrong in ways we couldn't reproduce).

[nickva]

I like this change, it simplifies things quite a bit. We'll have to check a bit more thoroughly but a preliminary quick bench shows the extra syscall costs about 3-5 microseconds

macos/intel

>element(1,timer:tc(fun() -> [file:position(Fd, eof) || I <- lists:seq(1,1000000)], ok end))/1000000.
3.739081

debian trixie/intel

f(Fd), {ok, Fd} = file:open("/var/tmp/f.txt", [binary, append, create,raw]).
(dbcore@db2.relengtest001.cloudant.net)5> element(1,timer:tc(fun() -> [file:position(Fd, eof) || I <- lists:seq(1,1000000)], ok end))/1000000.
4.243807

Another thing to keep an eye on is if this could acquire any extra locks or affect concurrency. Say would 10k couch_file doing an extra lseek call hit any possible bottleneck in the os layer (I would wager, not but worth thinking about)