Add utilities for hooking and chaining methods calls along tensor chains

[karlhigley]

Description

Adds utilities for inserting optional _before_method()/_after_method() hooks on a method decorated with @hookable, which allows custom tensor types to insert any functionality they individually require before or after a generic tensor method like send. This should help clean up the copious if isinstance(self, TensorClass) code in AbstractTensor and beyond.

In order to make sure that all custom functionality for types in the tensor chain gets called, this also creates a chain_call() function, which accepts a method name with args/kwargs, and calls that method (if it exists) on every tensor in the chain from outermost to innermost, returning the results in an ordered list.

Type of Change

Please mark options that are relevant.

• Bug fix (non-breaking change which fixes an issue)
• Documentation (non-breaking change which adds documentation)
• Improvement (non-breaking change that improves the performance or reliability of existing functionality)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)

Checklist

• I did follow the Contribution Guidelines
• I did follow the Code of Conduct
• I have commented my code following the OpenMined Styleguide
• I have added tests for my changes

[karlhigley]

Here are some examples of the kinds of code I'm trying to remove:

• TorchTensor.send() checks permissions on the whole tensor chain before sending a tensor, which means it has to know about functionality that properly belongs in PrivateTensor.
• TorchTensor.send() checks child types in order to determine whether or not to reset the garbage collection flag.
• TorchTensor.send() checks several flags to determine how to handle gradients, in order to make AutogradTensor compatible with MultiPointerTensor.

With _before_send() and _after_send() hooks that get called on each tensor in the chain, we should be able to move that kind of code into the relevant classes and avoid creating loops in the dependencies of the abstract and custom tensor types.

[codecov]

Codecov Report

Merging #3636 into master will increase coverage by 0.01%.
The diff coverage is 100.00%.

@@            Coverage Diff             @@
##           master    #3636      +/-   ##
==========================================
+ Coverage   94.68%   94.70%   +0.01%     
==========================================
  Files         161      163       +2     
  Lines       17246    17294      +48     
==========================================
+ Hits        16330    16378      +48     
  Misses        916      916              

Impacted Files	Coverage Δ
syft/generic/abstract/hookable.py	100.00% <100.00%> (ø)
test/generic/test_hookable.py	100.00% <100.00%> (ø)

[iamtrask]

this is a nice convenience function - although I'm not sure that we ever truly go more than one child deep (or two children deep in special circumstances) within any call. I do assume that you have a use for it in mind though.

[karlhigley]

Yeah, we don’t usually reach very far into the chain yet, but having stared at the code for a while, it’s starting to look like it would get simpler/cleaner if we did. There are also a few ad-hoc implementations of this pattern floating around.

[iamtrask]

Oh! I get it... wow that's clever! Love that!

[iamtrask]

This does overlap with ObjectConstructor a bit - but I'm ok with it given that ObjectConstructor doesn't exist yet - and there's a good chance they'll actually be compatible pieces of functionality with each other (aka ObjectConstructor creates the method names which this decorator detects)