SWE-2449 upgrade junos gem

[hwnjng]

Rebased our fork's master with original. Then rebased this branch with master.

[jordan0day]

So, I did some initial testing on this change last night to see how/if it affected narwhal, and I am seeing some interesting behavior we'll probably want to try to hunt down.

You'll want to update your narwhal's gemfile to point to this branch:
gem 'junos-ez-stdlib', git: 'https://github.com/packethost/ruby-junos-ez-stdlib.git', branch: 'SWE-2449-upgrade-junos-gem'
and run a bundle install.

Then, with your local (or dockerized) narwhal up and running (and the lab CSR enrolled), you can run a script like:

#!/usr/bin/env bash

SWITCH='csr1.lab1.packet.net'
PORT1='xe-0/0/65:0'
PORT2='xe-1/0/65:0'

HOST='http://localhost:9090'
UUID='test'
SECRET_KEY='test'
CONTENT_TYPE='application/json'
DATE=$(TZ=GMT date "+%a, %d %b %Y %T %Z")

METHOD="POST"
URI="/devices/$SWITCH/ports"

# { "interface": "xe-0/0/17" }

RESPONSE=$(curl -sS --request "$METHOD" --url "$HOST$URI" -H "Content-Type: $CONTENT_TYPE" -H "Authorization: APIAuth $UUID:$(echo -n "$METHOD,$CONTENT_TYPE,,$URI,$DATE" | openssl dgst -sha1 -binary -hmac $SECRET_KEY "$@" | base64)" -H "Date: $DATE" -d @- <<EOF
{	"interfaces": [ { "interface": "$PORT1" }, { "interface": "$PORT2" } ],
	"addresses": [ { "address": "10.1.1.1/24" } ],
	"description": "Some port name"
}
EOF
)

echo $RESPONSE | jq

Actually, maybe run the script once on an unmodified narwhal, and then change your Gemfile and re-run it, so you can compare before-and-after. Regardless, when I run the script above on an unmodified narwhal, everything works a-ok. When I run it on a narwhal updated to use the new branch, I get a nasty-looking error (though the commit does seem to succeed, still?)