[foreign-preview] RFR: 8282626: Revert semantic of session accessors [v6]

[Maurizio Cimadamore]

> This patch reverts the hook to make session accessors return a non-closeable session view.
> 
> This hook makes it harder to use segments that are backed by a one-off session; consider this case:
> 
> 
> SegmentAllocator malloc = MemorySegment::allocateNative;
> MemorySegment segment = malloc.allocate(100); // no way to close this
> 
> 
> In other words, the asymmetry we added to the API requires clients to perform a lot of tracking to be able to associate segments back to their sessions, creating an obvious scalability problem.
> 
> Moreover, the existing hook only protects against close. Clients of a segment can still allocate on a session they might not supposed to, or make the session uncloseable, by registering an infinite close action on it.
> 
> At the same time, when looking at how sessions might be used by APIs, usage patterns seem to fall in two categories:
> 
> * **External session**. APIs that need to create a resource (e.g. a matrix) will take as input a session, which indicates the lifecycle associated with the resource they want to create. In this case, securing the session is not necessary, as the API is getting the session from somewhere else. It is the *client* of the API that has to trust the API not to mess up with its session (but if the API does something shady with the client session, that's arguably a bug in the API). Code generated by jextract falls in this category, as well as [pooled allocators](https://github.com/openjdk/panama-foreign/pull/509).
> 
> * **Internal session**. Some APIs might want to hide sessions from clients; in such cases, the session will be created in the constructor, along with all the resources associated with it. In these cases, as the API has already provided some encapsulation, it seems sensible for the API to keep encapsulating resources associated with the session created internally. The code I've seen for both Lucene and Netty falls in this category.
> 
> In other words, making memory segments more principled only provides real benefit for APIs that combine both approaches; so far we don't have much evidence that such APIs exist (but if you have some use cases, we'd be interested to know!).
> 
> Considering all this, it makes sense to revert the API so that session accessor retain full powers.
> 
> This patch leaves the `isCloseable` predicate (still useful to query if a session can be used) as well as `equals/hashcode` (as moving away from `==` will keep our options more open).

Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:

  Remove unused import

-------------

Changes:
  - all: https://git.openjdk.java.net/panama-foreign/pull/661/files
  - new: https://git.openjdk.java.net/panama-foreign/pull/661/files/0df9aab0..c6647495

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=panama-foreign&pr=661&range=05
 - incr: https://webrevs.openjdk.java.net/?repo=panama-foreign&pr=661&range=04-05

  Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod
  Patch: https://git.openjdk.java.net/panama-foreign/pull/661.diff
  Fetch: git fetch https://git.openjdk.java.net/panama-foreign pull/661/head:pull/661

PR: https://git.openjdk.java.net/panama-foreign/pull/661