Expose *InvocationExpressionAttribute classes

[jnfeinstein]

The entirety of the expression-based PrePostAdvice interceptor chain is already public with the exception of these two classes. Making these public will allow consumers to build custom PrePostAdvice interceptor implementations on parity with the provided classes, without needing to duplicate code.

Per #4841, this should allow downstream consumers who only care about reactive implementations to do so without copying and pasting existing code.

[pivotal-issuemaster]

@jnfeinstein Please sign the Contributor License Agreement!

Click here to manually synchronize the status of this Pull Request.

See the FAQ for frequently asked questions.

[pivotal-issuemaster]

@jnfeinstein Thank you for signing the Contributor License Agreement!

[jnfeinstein]

@rwinch wondering if this might land on your plate 😃

[rwinch]

I think where this lands is going to depend on what things look like after gh-8996 is completed

[jnfeinstein]

I am not certain they cover the same issue. Does #8996 target reactive method security?

[jzheaux]

@jnfeinstein the work for method security was split out into #9350

[jnfeinstein]

@jzheaux does #9350 cover reactive method security? I haven't been able to get a clear answer and I'm not familiar enough with the code to deduce for myself. Happy to close if desired.

[jzheaux]

@jnfeinstein no, it doesn't, though the pattern ultimately followed in #9350 may determine what's done for reactive in #9401.

I think it's okay to leave this open for the time being since #9350 and #9401 are not resolved.

[eleftherias]

I'm going to mark this PR as blocked on #9401.
We should revisit it once #9401 is closed.

[jzheaux]

Now that #9401 is closed and these classes are deprecated, I think we should leave them be and encourage folks to migrate to AuthorizationManager.