New Sqlite instrumentation

[stefanosiano]

📜 Description

auto install of sentry-android-sqlite module
added Sqlite new instrumentation

💡 Motivation and Context

We want to refactor the database instrumentation moving as much as we can to the Java side, decreasing the need of bytecode manipulation.
The sdk side was convered in getsentry/sentry-java#2722
Here is the tracking issue: #401

💚 How did you test it?

📝 Checklist

• I reviewed the submitted code
• I added tests to verify the changes
• I updated the docs if needed
• No breaking changes

🔮 Next steps

[github-actions]

	Messages
📖	Do not forget to update Sentry-docs with your feature once the pull request gets approved.

Generated by 🚫 dangerJS against fad50b6

[romtsn]

Awesome job! There's 2 points I think that need attention - compatibility and a bytecode visitor test, but the rest is looking really good.

[romtsn]

nit: I think there's one uncovered case with this approach, for example:

private val delegate: OpenHelper.Factory

private fun wrap(configuration: OpenHelper.Configuration): OpenHelper {
  return delegate.create(configuration)
}

override fun create(configuration: OpenHelper.Configuration): OpenHelper = wrap(configuration)

in this case we'd still instrument it, because delegate.create(configuration) is outside the create method scope. But I think this is still fine and it's more of an edge case; we can always come back to it if someone reports an issue.

[romtsn]

Another weird thing - I tried to run it locally and decompile afterwards, and I see this weird bridge synthetic create method in AutoClosingRoomOpenHelperFactory:

However, I have no idea where it's coming from, the implementation doesn't look much different from the other open helpers they have. So I'm guessing it's still fine, because the other create method is properly not instrumented. Maybe it's a bug in the decompiler tool not sure

[romtsn]

bottom line: nothing to address here, just we should be aware of both of these things :)