Fix problem with client RIDs being reused when more then 65536 records

[dxmaxwell]

The use of htons caused the RID to increment is steps of 65536 and as a resulted limited the number of unique RIDs to 65536. The problem can be masked if the server create small Transaction objects that contain less than 65536 records.

This should explain at least some of the salability (#27) problems we have been seeing.

@mdavidsaver I tried to find all places where rid is assigned, but I would appreciate your review.

[mdavidsaver]

Copy+paste strikes again... I'll take a look.

[mdavidsaver]

A couple of minor points. My build with stack-protector turned up a bug triggered by test code only (yes there is test code). mdavidsaver@5ba50bb

This test code needs a corresponding change for the RIDs, which I had consistently wrong. 3a0bb2e

Also, I made at attempt at travis-ci.org config, by copying another project, but I seem to have confused travis-ci by reusing the origin repo name for a fork, (oops I forgot). So I haven't checked this yet. Hopefully I haven't confused github as well 0ca8dc7

[dxmaxwell]

Bump @mdavidsaver What is needed to merge this PR? I have some server changes ready for a PR, but would prefer to have this merged first.

[mdavidsaver]

Will you pull in the changes I mentioned previously to this branch/PR?

[dxmaxwell]

Done. The changes to client/configure/RELEASE gave me problems in testing and I needed to revert it, is that correct? Looks like a development configuration.

[mdavidsaver]

The newer convention is to ship configure/RELEASE with only comments. Users then write a unversioned file configure/RELEASE.local with configuration.

Of course you can revert if you like.

[dxmaxwell]

I support adopting better conventions, but I'm trying to understand my options. My goal is to have the package built from this repository be compatible with the other epics-base packages. If this was a standard package then I could patch in the RELEASE.local file, but since this is a native package that doesn't work. Another solution is to add the RELEASE.local file to the FRIB internal repository, but that doesn't help anyone else.

Looks like I can either revert the file, or convert this to a standard Debian package. Any other ideas?

[mdavidsaver]

For the package build, the answer is easy. Write configure/RELEASE.local before make, then clean it.

https://github.com/epicsdeb/devlib2/blob/master/debian/rules#L9

[dxmaxwell]

That works! I've made the change. If it looks complete, please merge it.

[dxmaxwell]

@mdavidsaver I found that I needed to remove RELEASE.local just before the dh_install command because the '--fail-missing' option is used. I noticed from the build log that EPICS Debhelp already cleans up the RELEASE file during dh_epics_postinstall:

22:41:28 make[1]: Leaving directory '/build/recsync-1.3.4+frib6+0~20190321023951.18+debian09~1.gbp67a07f'
22:41:28    dh_epics_postinstall -O--parallel
22:41:28 	rm debian/tmp//usr/lib/epics/configure/RELEASE
22:41:28    dh_epics_installlibs -O--parallel
22:41:28 	install -m 755 -d debian/tmp/usr/lib/x86_64-linux-gnu
22:41:28 	mv debian/tmp//usr/lib/epics/lib/linux-x86_64/libreccaster.so.1 debian/tmp/usr/lib/x86_64-linux-gnu/libreccaster.so.1
22:41:28 	rm -f debian/tmp//usr/lib/epics/lib/linux-x86_64/libreccaster.so
22:41:28 	ln -s ../../../x86_64-linux-gnu/libreccaster.so.1 debian/tmp//usr/lib/epics/lib/linux-x86_64/libreccaster.so
22:41:28    dh_epics_install -O--parallel
22:41:28 	epics-recsync-dev EPICS devel package

Perhaps EPICS Debhelper should also remove RELEASE.local if it exists?