refactor template instantiation

[jmjatlanta]

This is another way to fix #1504 that works for macOS, and probably others.

Instead of including fc/smart_ref_impl.hpp, this fix permits the template to generate the specific copy constructor that is needed.

I am unable to test on the originally reported platform (openSUSE 15.04) , as I do not have that environment.

[jmjatlanta]

Note: I threw in another fix that is not related to the above, but does allow for compilation on macOS. I thought it too small for a separate PR, but it is in a separate commit (regarding size_t to uint64_t) should others think it better to separate them.

[pmconrad]

Travis build fails with "ambiguous template specialization"

[pmconrad]

Commit message should indicate that the "variable" is the next sequence counter used by database indices.

[jmjatlanta]

Travis build fails with "ambiguous template specialization"

Hmmm. It compiles fine in Release mode, but I can replicate the failure in Debug mode. Interesting I will investigate.

[jmjatlanta]

Travis build fails with "ambiguous template specialization"

I have looked through the code, and unless I am missing something big, this smart_ref stuff is of little use. It is only used in fee_schedule.

Of course, because of its use there, there needs to be code to serialize and de-serialize it. Plus the actual template definitions. And you will need to include the smart_ref header everywhere you use fee_schedule.

It seems like a whole lot of hoops to do what I think a smart pointer could do.

Then there are problems with the template on mac. It seems to have been causing problems on that platform for a while, as a static "tmp" of smart_ref<fee_schedule> was added a few years ago to allow mac to compile it.

In an attempt to fix recent mac issues, adding a simple forward-declare causes problems with the overloaded ! operator.

All of the above makes me think about ripping it out. But two issues appear:

1. Am I not seeing something that smart_ref does that some kind of pointer does not?
2. If it were to be ripped out, what would need to be done to make things backward-compatible with serialized objects?

Looking for input/opinions.

Note: I can fix the mac overloaded ! by doing a specialization. It is an easy fix, but the above questions remain.

[pmconrad]

Hm, this looks somewhat useless indeed.

Serialization of smart_ref<T> is identical to serialization of T, except for one level of nesting in raw serialization. Possible replacement would be std::unique_ptr, with the caveat that smart_ref cannot contain a null pointer, plus there is no raw serialization for std::unique_ptr yet AFAICS.

[pmconrad]

As discussed previously, let's merge this as a quick fix and aim for a proper solution later on.

[jmjatlanta]

The real fix will be done as part of #1548. This fix just eliminates the need to put a header in a bunch of files. Compiles fine on Ubuntu 18.10, macOS 10.13. Windows build seems to be going fine, will update here if there are any issues.