Reproduction steps:

• The server is running any 1.18.x version. I initially noticed this issue when updating to 1.18. If I remember correctly, I was not able to reproduce the issue on 1.17.
• A player is standing more than 6 blocks away from some chest. If the player is standing closer to the chest, this issue is not observed.
• A plugin opens the inventory of that chest for the player, via `player.openInventory(chest.getInventory())`. Example reproduction code:

int x = ...
int y = ...
int z = ...
Block block = player.getWorld().getBlockAt(x, y, z);
Chest chest = (Chest) block.getState();
player.openInventory(chest.getInventory()); 

Expected:

The chest block switches to its open lid state, and closes again once the player closes the inventory again.

Observed:

The chest lid opens and immediately closes again.
The chest lid state remains inverted for the player until they rejoin the server: When they close the inventory, the chest lid opens. When they subsequently manually open the chest by interacting with it, the chest lid closes, etc.
Actually, as long as the chunk with the chest remains loaded, the inverted chest open state will also persist: Once a freshly joined player interacts with the chest, the server will send them the incorrect 'inverted' open state.

My guess is that the cause of this behavior can be found in `ContainerOpenersCounter#recheckOpeners`:

• This is called during ticking of the chest block.
• This checks if there are still players nearby (in a ~5 block radius) that have the chest open.
• Since the player is further away than that, the chest lid is closed again.
• Once the player actually closes the chest inventory again, the 'openCount' is reduced further. My guess is that this is set to a value of -1, which might be displayed by the client as 'open'.
• Once the chest is opened again, the 'openCount' is incremented to 0, which is displayed as closed on the client.

A possible solutions could be to make sure that the 'openCount' value remains in valid bounds, i.e. does not become negative.
However, since 'recheckOpners' is called at some tick after the chest was opened, this will still result in the chest being briefly opened. Ideally, the chest lid should not actually be opened in the first place if the player is already too far away in the beginning, since Minecaft apparently does not intend to remain it open anyways.

Unrelated to that: In the past, I liked the behavior that the chest would indicate that it is being interacted with, even if the player is slightly more than 5 blocks away. With the above fix, I guess plugins will now have to manually replicate the chest opening/closing animation + sounds when they want to retain the previous behavior.