RFR 15 8243099: SO_INCOMING_NAPI_ID support

[Chris Hegarty]

> On 30 Apr 2020, at 22:20, Ivanov, Vladimir A <vladimir.a.ivanov at intel.com> wrote:
> 
> One more update at http://cr.openjdk.java.net/~sviswanathan/Vladimir/8243099/webrev.05/
> The @apiNote section was updated a little bit to concentrate on SO_INCOMING_NAPI_ID.

I have not seen much discussion relating to possible approaches to this
new (first-time in the JDK?) read-only socket option.

The current semantic, that an option returned from `supportedOptions`
will not result in an UnsupportedOperationException when passed to
`getOption` or `setOption`, is quite nice - this current proposal will
change that.

The `getOption` and `setOption` methods specify that UOE is thrown "If
the socket option is not supported by this channel" - but with the
current proposal this is not the case - UOE will be thrown for this new
option even though the channel supports the option (`supportedOptions`
contains the new option).

Has any consideration been given to restricting the set of allowable
integer values that may be set for this option - say, to none? Which
would then lead to an IllegalArgumentException if `setOption` is
invoked in an attempt to set this socket option - since no given value
is allowable.

---

In terms of retrieval, is `0` a valid value for this option? if so then
uninitialized versus initialized states are indistinguishable. Maybe not
be a problem, I dunno yet without further investigation.

Also, when a non-0 value is read, is it guaranteed to remain constant
thereafter, or does an application need to periodically check the socket
option value.

-Chris.