Analyzer: Excluded non-Function methods from BindingAnalyzer

[amdeel]

This PR updates the BindingAnalyzer to only run analysis when the method being analyzed is located inside a Function.

resolves #2222

Pull request checklist

• My changes do not require documentation changes
  • Otherwise: Documentation PR is ready to merge and referenced in pending_docs.md
• My changes should not be added to the release notes for the next release
  • Otherwise: I've added my notes to release_notes.md
• My changes do not need to be backported to a previous version
  • Otherwise: Backport tracked by issue/PR #issue_or_pr
• I have added all required tests (Unit tests, E2E tests)
• My changes do not require any extra work to be leveraged by OutOfProc SDKs
  • Otherwise: That work is being tracked here: #issue_or_pr_in_each_sdk
• My changes do not change the version of the WebJobs.Extensions.DurableTask package
  • Otherwise: major or minor version updates are reflected in /src/Worker.Extensions.DurableTask/AssemblyInfo.cs

[cgillum]

Looking at the original issue and looking at the test code for this PR, I was surprised that the analyzer was flagging parameters for methods that aren't functions. My expectation was that the analyzer would only consider function parameters -i.e., parameters in methods that have the [FunctionName] attribute.

Would that be another way to solve this problem?

[amdeel]

@cgillum It's flagging the attributes because it's a method called in the orchetrator, so it's considered deterministic code. Do you think I should be checking code on orchestrator functions only for this analyzer instead?

[cgillum]

I was just wondering why the analyzer would check method parameters on arbitrary methods. It wasn't clear to me how method parameters relate to orchestrator code constraints. I was assuming that this particular check was looking for illegal binding parameters, which are only relevant in function signatures.

[amdeel]

@cgillum The deterministic analyzers currently analyze all orchestrator methods and methods called in orchestrators. I can just add a check on this analyzer specifically to prevent it from flagging code in methods without the FunctionName parameter on it, if you agree with that solution.

[cgillum]

I can just add a check on this analyzer specifically to prevent it from flagging code in methods without the FunctionName parameter on it

This sounds great to me. This approach also helps ensure that we don't accidentally flag other parameter attributes, including custom parameter attributes (those written by the user and not provided by the framework) that we couldn't possibly know about ahead of time.