Fix support for 1.11

[JamesWrigley]

See the commit messages for details, TL;DR IOBuffer.data became a Memory in 1.11 so I made the old Message(::Array) constructor into a Message(::DenseVector) to support it.

[codecov-commenter]

⚠️ Please install the to ensure uploads and comments are reliably processed by Codecov.

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 83.10%. Comparing base (7f070fe) to head (cf4b89c).
Report is 1 commits behind head on master.

Additional details and impacted files

@@            Coverage Diff             @@
##           master     #244      +/-   ##
==========================================
+ Coverage   78.74%   83.10%   +4.35%     
==========================================
  Files           9        9              
  Lines         367      367              
==========================================
+ Hits          289      305      +16     
+ Misses         78       62      -16     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[JamesWrigley]

Removed JET from the tests because getting compat bounds is annoying...

[stevengj]

LGTM.

[JamesWrigley]

This isn't quite ready to merge yet, the tests uncovered a weird bug 😬

    s1 = Socket(PUB)
    s2 = Socket(SUB)
    ZMQ.subscribe(s2, "")
	ZMQ.bind(s1, "tcp://*:5555")
	ZMQ.connect(s2, "tcp://localhost:5555")

    # Message(::Int) - construct from buffer size
    data = rand(UInt8, 10)
    m1 = Message(length(data))

    # copy!(m1, data) <- this works
    # m1[1] = data[1] <- this works (as far as a single element goes)

    # This causes recv() to hang
    for i in 1:1
        m1[i] = data[i]
    end

    ZMQ.send(s1, m1)
    @test ZMQ.recv(s2) == data

I'm not really sure what's going on there, do you have any ideas? I'm guessing that we're hitting undefined behaviour or memory corruption or something. This is why CI is hanging.

[JamesWrigley]

It seems to be an old bug too, I was able to reproduce it on v1.2.3. I guess this particular functionality was almost never used so the bug never appeared. And even weirder, doing a task switch from printing something will also fix the hanging.

[JamesWrigley]

So if this code is exited the timer will fire:

    x = () -> begin
        s1 = Socket(PUB)
        s2 = Socket(SUB)
        s1.sndhwm = 100
        s2.rcvhwm = 100
        ZMQ.subscribe(s2, "")

	    ZMQ.bind(s1, "tcp://*:5555")
	    ZMQ.connect(s2, "tcp://localhost:5555")

        data = rand(UInt8, 10)
        m1 = Message(length(data))

        ZMQ.send(s1, m1)
        t = @async @show ZMQ.recv(s2)

        timer = Timer(2) do timer
            @info "Sending"
            ZMQ.send(s1, "foo")
        end

        wait(t)
        close(timer)
    end
    x()

But if the lambda is commented out and it's executed within a @testset the timer doesn't fire. Somehow that first message is getting dropped when in a lambda, which makes me think that the indexing is a red herring and it's actually GC related. Then again, inserting GC.gc(true) calls doesn't break the code when not in a lambda and the sockets do still work so clearly it's not the sockets/context getting GC'd.

[JamesWrigley]

NVM, turns out this is just a ZMQ thing 🤦 It's the slow joiner problem: https://stackoverflow.com/a/15175698

Interesting demonstration of how different things can affect performance.