RTEMS socket close() hack

[mdavidsaver]

RTEMS allows blocking sockets to be interrupted by shutdown() (aka. esscimqi_socketBothShutdownRequired). However, a concurrent close() is a race which can leave a send()/recv() call permanently stuck! The right way to handle this (aside from fixing the stack) would be to sequence shutdown() -> exitWait() -> epicsSocketDestroy(). This is hard to handle since this must be done for both sender and receiver thread, which presents difficulties owing to how the Transport hierarchy is structured since Transport::close() can happen on either worker, or a user thread.

Rather than try to straighten this mess out properly, we add this "wait" in-between shutdown() and epicsSocketDestroy() to hopefully wait for the workers (or other worker) to return from send()/recv().

cf. #150

[mdavidsaver]

So far this problem has not manifest for (or hasn't been reported by) users. However, it does appear if the remote/ unit tests are run for RTEMS, and results in hung tests.

I don't think this will have ill effects for actual applications/IOCs.

I'm also disabling testChannelAccess for RTEMS as it has two failures which I'm not going to investigate at present.

   testChannelAccess.tap ..... 
  not ok 22 - void ChannelAccessIFTest::test_channel(): channel state change count should increase on the destroyed channel
  not ok 25 - void ChannelAccessIFTest::test_channel(): a destroy event was caught for the testing channel that was destroyed twice 
  Failed 4/152 subtests 
  	(less 12 skipped subtests: 136 okay)

[mdavidsaver]

Merging now so that CI passes when I update the modules/pvAccess in Base.